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

autefrum's avatar

New install - had to chmod -R 777 storage folder to get it working - problem?

After hit the /public folder in a newly installed laravel 5.5 on my Centos apache machine, I received 'Opps!' page errors saying the php could not open the log as file storage/logs/laravel

Apache is running as user 'apache', and the logs folder has drwxr--r-- so I changed it to drwxrwxrwx using chmod -R 777 storage

I have not had to do this previously as I was installing on XAMPP on Windows (different approach to multi user file security).

Is this a problem? Or is it fairly normal?

I installed using composer create project, not laravel new.

0 likes
6 replies
burlresearch's avatar

Windows and Xampp have a completely different approach to filesystem security - so none of that applies on your LAMP deployment.

It's best NOT to use world-writeable permissions on your production deployment. (Being the 3-rd '7' in your chmod).

But getting this to work otherwise means that - the user the web-server is running as will need write permission to certain directories (like the one the the log-file lives in).

One thing you can do, is to make this folder subtree writeable by the apache group. This seems somehow a better practice to me:

$ chgrp -R apache storage
$ chmod -R ug+rw,o-rwx storage

Thus the webserver can still write the files it needs and your filesystem perms still make some sense.

autefrum's avatar

Good idea. Done! My ls -l line is now:

drwxrwx--x 5 root apache 4096 Jan 4 00:52 storage

Thanks!

burlresearch's avatar

Deploying your app under the 'root' user is where your problem began ... this is an anti-pattern also.

The 'root' user is intended to be reserved for system administration and OS-level processes - typically you want to have another user on the system with which you can deploy and manage your production deployment.

Server management is a big topic, if you want to see some best-practices, @TaylorOtwell has given us some great tools for helping with all of this stuff:

These could be worth trial-ing to see how things are setup.

ejdelmonico's avatar

Take the advice given to you. Your server is easy to hack the way you are configuring your users. You are configuring for convenience instead of security. Unfortunately, that is what most people do and it is so easy to hack that any teenager could do it if they were interested. When configuring your server 1) always use selinux if applicable, 2) disable the root account after making another user account without sudo privileges (you can just su and type root password when necessary), 3) in your case, change owner of your web server to apache since that is the group you are using. Make user with limited privileges for your DB. There is a lot more advice and it becomes time consuming so do yourself a favor and use the Forge service and you won't have to worry much.

autefrum's avatar

I appreciate everyone's advice on security here - but the server is inside our firewall, not accessible to the internet, and contains only sample rubbish data. I am using it to develop a sample minimum viable product for evaluation internally. I will take more security precautions when (and if?) we take this to the next step. I'm even reckless enough to be using mysql credentials of root with no password on this machine!

autefrum's avatar

Just thought I would update this question with what I did to get this working on AWS, partly to thank the participants for their security advice, and partly so someone else reading this knows how to get Laravel 5.5 working on AWS EC2.

Firstly I had to use a t2.micro instance as it had 1GB of RAM. i found composer would not install Laravel with .6GB of RAM, which is what the t1.nano (I think, or was it t2.nanao?) instance came with. I could have opted to install a swap file as discussed here: https://medium.com/@james_fairhurst/using-laravel-forge-to-setup-an-aws-server-7da83f760a56

I The httpd service is running as a user 'webapp'. this user is the owner of the storage folder, which means the apache tasks can write to those log files etc that was the initial reason I raised this question.

Please or to participate in this conversation.