As a general rule of thumb, no matter what it has to do with, if anyone ever suggests you should chmod 777 anything or likewise allow "all" permissions in Windows just walk away from the advice entirely. The spread of advice like that on the internet is just one of the reasons why Wordpress has it's reputation in security. Part of being a developer (whether it's ultimately going to run on Windows Server, Linux, or FreeBSD) is knowing some quality server administration skills, you can't escape it. Also on a bit of an off-topic, some advice on picking a server OS: the right one to use is the one you actually know how to use.


Please run this in the sequence they are

sudo find {laravel-folder}/ -type f -exec chmod 644 {} ;

sudo find {laravel-folder}/ -type d -exec chmod 755 {} ;

sudo chmod -R 777 {laravel-folder}/storage

sudo chmod -R 777 {laravel-folder}/bootstrap/cache/

1 year ago (2,190 XP)

The most security-informed consensus above seems to suggest files have 644 and directories 755.

I am not sure why you want to be giving all users any permissions in your laravel codebase. For this reason, I'd suggest 640 and 750.

Further, I see no reason to limit access to your own user. So I give myself full RWX access (i.e. 740 and 750), meaning I can execute shell commands etc on the production server. This is handy for running (for example) $ npm run production to have Laravel Mix compile all your stuff. I do this in a CI script.

Finally, if you set the setgid on your directories, anything created inside them will automatically be given the www-data group, which means if your own user creates files in the site codebase (e.g. by running Laravel Mix as above) these files will automatically be readable by your server.

To summarise, I suggest files get 740, and directories get 2750, and the storage and bootstrap/cache directories get 2770 (the leading 2 is the setgid bit).


so ive spent the past day mucking around with laravel permissions and using the stringent permissions guide given as "best secure practice" by this thread, and having real issues editing and even creating new files in the dirs!!

super frustrating to say the least.

centos 7...webserver runs as apache:apache im currently user marke with apache as primary group and wheel as secondary group.

if i set files (as root or sudo of course) as 644 i cant write them as marke of course..only apache user can write them but i am not trying to log is as apache and in fact think it would be poor practice to give any real user access that that username.

Are you guys advocating that I should log in as apache? or even give another more insecure user/developer access to that account?? that seems like madness to me.

Or am I missing something fundamental here? I can't see how I am because 644 only give write access to owner.

I look forward to hearing where I'm off.


This is good to use 600 permission for .env files.


@bashy running that command will make the storage folder 774. Is that okay? Are intending for that to happen?

5 months ago (1,002,600 XP)

@kendanblvnp I've updated my reply as ACLs are implemented more in Linux. See if those work better. 774 is fine. The last number is the 'public' permissions so as long as it's not 7, it's not readable and writable by other users.


Best Answer on this worked for me (log file not having permission to write on a new install), but it's worth pointing out to the people who were struggling with this and choosing an unsafe 777 work around:

www-data is not always the user running your webserver (apache, etc)

In my server's case (bitnami on AWS --doing a clean install, not using their pre-installed laravel) 'daemon' was the user needed for the 'group' permission.

The key is that your webserver's user ('www-data' in the Best Answer example) is able to write to the necessary folders. Setting the group to your SSH/SFTP access user might let YOU write to the folders/files you need, but not allow the webserver to do so.


2 months ago (1,002,600 XP)

@SimonEsposito That's why ACL is best since it'll allow you to set who can read/write/execute and doesn't matter about owner/group.


Check this out, it got it working for me, on centos7 Do not forget to run restorecon -Rv /var/www/html/ This did the trick for me on centos 7 on a laravel project that i set up and access via virtual box.

Please sign in or create an account to participate in this conversation.