If you’re running a self-hosted Snipe-IT instance and suddenly encounter a 500 Internal Server Error, one of the most common causes is incorrect file or directory permissions — especially after restoring from a backup, migrating to a new environment, or using volume mounts with Docker.

Here’s how I resolved this issue in both Docker-based and non-Docker (bare-metal or VM) environments.

🧭 Symptoms

  • Snipe-IT displays a 500 Internal Server Error after loading.
  • Uploaded logos or files don’t appear in the web interface.
  • storage/logs/laravel.log shows permission denied or file not found errors.
  • PHP or Laravel cannot write to required directories.

🛠️ Root Cause

Snipe-IT is built on Laravel, which requires write access to specific directories:

  • storage/
  • bootstrap/cache/
  • storage/uploads/ (accessed via public/uploads/ via symlink)

If the web server user (typically www-data) can’t read or write to these directories, Snipe-IT crashes with a 500 error.

✅ Fix for Docker-Based Setups

If you're running Snipe-IT via Docker, follow these steps.

Step 1: Fix permissions inside the container

docker exec -it snipeit bash

chown -R www-data:www-data /var/www/html
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;

php artisan storage:link
php artisan config:clear
php artisan config:cache

Step 2: Fix volume permissions on the host

If you’re using a bind mount like:

volumes:
  - ./snipeit-data:/var/www/html

Then the container is using your host’s permissions, and fixing them inside the container won’t help. Do this on the host instead:

sudo chown -R www-data:www-data ./snipeit-data
sudo find ./snipeit-data -type d -exec chmod 755 {} \;
sudo find ./snipeit-data -type f -exec chmod 644 {} \;

Restart the container to apply changes:

docker-compose down
docker-compose up -d

✅ Fix for Non-Docker / Traditional Installations

If you're running Snipe-IT on a regular Linux server or VM (Apache or Nginx), use the following steps.

Step 1: Set correct permissions

cd /var/www/snipe-it

sudo chown -R www-data:www-data .
sudo find . -type d -exec chmod 755 {} \;
sudo find . -type f -exec chmod 644 {} \;

php artisan storage:link

Step 3: Clear Laravel config cache

php artisan config:clear
php artisan config:cache

Step 4: Restart the web server

Depending on your setup:

sudo systemctl restart apache2
# or
sudo systemctl restart nginx php8.1-fpm

Make sure you match the correct PHP-FPM version (php7.4-fpm, php8.2-fpm, etc.).

🧪 Still Not Working? Check the Laravel Logs

Use this command to tail the log file:

tail -f storage/logs/laravel.log

Look for errors related to permissions, storage paths, or missing symlinks.

📋 Summary

Task Docker-Based Non-Docker / Bare-Metal
Fix ownership On host with chown -R www-data On filesystem directly
Fix permissions In container and/or on host On filesystem directly
Create storage symlink php artisan storage:link Same
Clear Laravel cache php artisan config:clear && config:cache Same
Restart service docker-compose restart systemctl restart apache2 or nginx

💡 Conclusion

A 500 Internal Server Error in Snipe-IT after a restore or migration is usually caused by Laravel not being able to write to key directories. Whether you're using Docker or hosting directly on a server, correcting file and folder ownership and permissions — and ensuring the storage symlink is in place — is often all it takes to bring your instance back online.

📝 Like this post?
Read more real-world DevOps and self-hosting stories at:
👉 blog.opensourceitsolutions.co.uk

🏷️ Tags

#snipe-it #laravel #500 error #docker #linux permissions #troubleshooting #self-hosted #open-source #devops #sysadmin