Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

JeffH's avatar
Level 8

File Permissions Question

Hello!

Quick question regarding file permissions. My current setup is to push code to github and the server admin pulls and does whatever.

I am using wsl2.

  1. wsl (log in as root)
  2. su jeff (switch to jeff)

I followed this guide to install everything https://tecadmin.net/install-laravel-ubuntu-20-04/

So the problem is that every time I push code, the server admin messages me saying its broken because of. Which sounds like a server issue, but he has a bunch of other developers pushing code and mine is the only one causing this problem? file_put_contents(/var/www/{application}/storage/framework/cache/data/85/5f/855f92484c8c414d36c1b25cb24876e30229cbbf): Failed to open stream: Permission denied

I'm pretty weak on linux side. So i decided to completely wipe my wsl environment and try again. Thinking maybe i ran things as root?

anyway. When i do ls -l to see permissions locally, its jeff www-data example:

-rw-rw-r--   1 jeff     www-data   3971 Mar  4 09:18 README.md
drwxrwxr-x  20 jeff     www-data   4096 Mar  4 09:18 app

could this be causing issues?

I also noticed that when I do things like php artisan make:controller TestingController, the file permission is jeff jeff

 -rw-rw-r-- 1 jeff jeff        124 Mar  4 11:26 TestingController.php

am i doing something wrong? Any tips would be nice

also, before wiping the wsl2 instance all my permissions were set to jeff jeff

drwxrwxr-x  20 jeff     jeff  4096 Mar  4 09:18 app

I thought this was maybe the reason, so i did the full wipe which now has jeff www-data

Just wondering if this should also fix it

0 likes
1 reply
LaryAI's avatar
Level 58

It seems like the issue you're encountering is related to file permissions and ownership. When you create files locally, they are owned by your user (jeff) and your group (jeff or www-data), but when these files are pulled onto the server, they need to be accessible by the web server user (often www-data or similar).

Here are a few steps to ensure proper permissions and ownership:

  1. Set the correct ownership: Make sure that the files and directories in your Laravel project are owned by the correct user and group. On your local machine, you can set the group to www-data (or whatever group your web server uses) and give group write permissions.

    sudo chown -R jeff:www-data /path/to/your/laravel/project
    sudo chmod -R g+w /path/to/your/laravel/project
    
  2. Set the correct permissions for storage and bootstrap/cache directories: Laravel requires specific directories to be writable by the web server. You can set these permissions as follows:

    chmod -R 775 /path/to/your/laravel/project/storage
    chmod -R 775 /path/to/your/laravel/project/bootstrap/cache
    
  3. Use umask to set default group permissions: You can set a umask in your .bashrc or .bash_profile to ensure that new files are created with group write permissions by default.

    echo "umask 002" >> ~/.bashrc
    source ~/.bashrc
    
  4. Configure git to handle file permissions: Git has a configuration called core.fileMode which tells Git if it should track file permission changes. If your server admin is having to constantly fix permissions, you might want to set this to false in your local repository.

    git config core.fileMode false
    
  5. Use a deployment script: If the server admin is pulling your code, consider using a deployment script that sets the correct permissions after each pull. This script could reset the permissions to what the server expects.

  6. Communicate with your server admin: Since the server admin has to deal with multiple developers, it might be helpful to establish a common set of permissions and ownership that all developers should use. This way, you can configure your local environment to match the server's expectations.

Remember to replace /path/to/your/laravel/project with the actual path to your Laravel project. Also, be cautious with permissions: giving too broad permissions can be a security risk. Always aim for the principle of least privilege.

Lastly, ensure that your .gitignore file is properly set up to ignore the storage and bootstrap/cache directories, as these should not be tracked by Git and should be generated on the server side.

Please or to participate in this conversation.