Debugging Server Permissions

❗️

This article refers to web server file system permissions only

It does not address Snipe-IT application permissions.

One of the most common issues folks newer to running web servers run into is how to manage the Linux/Windows/etc owners and groups of the Snipe-IT filesystem.

As we mention many times in the installation documentation, nothing in Snipe-IT should be run as or owned by root. Running composer as root, for example, can cause you no end of grief later, as the git directories and composer directories may not be writable later on if you try to fix your install's permissions and miss those directories.

The exact permissions, ownerships and group memberships your web server needs for its files and directories will unfortunately vary quite a bit depending on what OS you're running and how you've got your web server software (Apache, Nginx, IIS, etc) configured.

Identifying Permissions Issues

The easiest way to identify permissions issues will be to search your storage/logs/laravel.log for the phrase permission denied. If you're running an upgrade using the upgrade.php script, this is even easier, as it outputs any issues it runs into. For example, if you see:

Text

error: cannot open .git/FETCH_HEAD: Permission denied
fatal: Unable to create '/var/www/snipe-it/.git/index.lock': Permission denied
error: cannot open .git/FETCH_HEAD: Permission denied

This usually means the initial install or a previous upgrade was run as root, so now root owns all of those files and directories (and subdirectories), and whatever user you're currently logged in as via the command line cannot write to those files and directories because they don't have permission.

If you see something like:

PHP

file_put_contents(/var/www/snipe-it/storage/framework/down): failed to open stream: Permission denied

That means that your storage directory or one of the files/directories within it cannot be written to.

❗️

DO NOT USE sudo TO ELEVATE YOUR PRIVS TO GET AROUND THIS!

Public-facing files should never be run as root as it opens you up to a variety of potential security issues. It's vastly better to actually fix the permissions so that they work as expected.

Digital Ocean has a great (if a little long) intro to permissions on web servers available here.

Fixing It

In Snipe-IT, there are a few main directories (and all of their files and subdirectories) that need to be written by the user you might be logged into your command line as. storage and public/uploads. If you don't have the correct permissions on public/uploads, your upgrades will go fine, but you won't be able to upload any images (logos, asset images, etc).

If you cannot write to the storage directory, things can break in much weirder ways, since it often tries to log an error, but the log file lives in storage/logs/laravel.log, so it can't even write to the log file sometimes.

Assumptions in the below example:

• Your linux username is my-user - you will change this to whatever you normally login to the server as
• The user your web server runs as is www-data - this is common in ubuntu and homestead but not guaranteed
• Your path to your Snipe-IT install is /var/www/snipe-it - this may or may not be the case, just substitute your correct path

Shell

sudo chown -R my-user:www-data /var/www/snipe-it
sudo usermod -a -G www-data your-linux-user
sudo find /var/www/snipe-it -type f -exec chmod 664 {} \;
sudo chmod -R 775 /var/www/snipe-it/storage
sudo chmod -R 775 /var/www/snipe-it/public/uploads
sudo chmod -R 775 /var/www/snipe-it/bootstrap/cache

Note that as we're setting the permissions, that's the only time we should be using sudo and then never again.