Laravel 5 permission denied when writing in log file
I have Ubuntu and Laravel 5 framework and I see the white screen in the browser.
When I change storage/logs directory permissions it helps, but I have to do it every day, due the ‘daily’ log configuration.
5 Answers 5
The permissions for the storage and vendor folders should stay at 775 , for obvious security reasons.
However, both your computer and your server Apache need to be able to write in these folders. Ex: when you run commands like php artisan , your computer needs to write in the logs file in storage .
All you need to do is to give ownership of the folders to Apache :
sudo chown www-data:www-data /path/to/your/project/vendor sudo chown www-data:www-data /path/to/your/project/storage Then you need to add your computer (referenced by it’s username ) to the group to which the server Apache belongs. Like so :
sudo usermod -a -G www-data userName Most frequently, groupName is www-data but you might want to replace it with your correct group.
Unfortunattely, your approach wouldn’t help. By default Apache creates new files with permissions 644 (-rw-r—r—). It means artisan can’t write to the same file whether it belongs to the www-data group or not.
You are right. I will delete my answer. However, you should consider adding the user to the www-data group and keeping 775, rather than 777 all the folder. We need a solution that works for production too.
I got the same error. By using the following command I could solve it. For some reason, it is not about the log file.
sudo chgrp -R www-data storage bootstrap/cache sudo chmod -R ug+rwx storage bootstrap/cache - chmod 777 is in general a security risk extremely risky.
- chmod 775 for the storage folder is fine considering user also
belongs to web server group. - with -R its extremely risky since for files an execute permissions is not at all required.
- chmod 664 for files inside storage. chmod 775 for folders inside
In config/login.php , check permissions are set:
'daily' => [ 'driver' => 'daily', 'path' => storage_path('logs/laravel.log'), 'level' => 'debug', 'days' => 14, 'permission' => octdec('0666'), ], As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.
Short answer:
sudo chmod -R 777 vendor storage
echo «umask 000» | sudo tee -a /etc/resolv.conf
sudo service apache2 restart
Extensive answer:
When you launch Laravel 5 framework on Apache server with enabled by default ‘daily’ option for creating log files, sometimes you would face with forbiddance of writing into logfiles due the file permissions.
Ususally, when you have php project all files belong to www-data user, and your current user has no need to write to logfiles.
Regarding the Laravel, two different processes need to write to your logfiles:
1) Apache server (user www-data ) when you do something in your browser;
2) Php process (your user) when you execute php artisan something in command line.
Of course, you can execute sudo -u www-data php artisan your_command (like suggested here ) each time you want to use artisan, but it is a bit annoying.
First of all you need to give permissions to vendor and storage directories for Apache user. Most easiest way (but not the best one) is to perform: sudo chmod -R 777 vendor storage
Now, lets see what happens when logfile creates in both cases.
If initially logfile storage/logs/laravel-2015-mm-dd.log was created through the error raised by php artisan something command (case 2), log file will have
permissions.
If it was created by your apache server (case 1), which ussually launch under www-data user, permissions will look like this:
So, my suggestion is to change permissins for newly created files by apache.
Let’s add line umask 000 to /etc/resolv.conf file.
echo "umask 000" | sudo tee -a /etc/resolv.conf sudo service apache2 restart That’s it.
Be aware, this solution is applicable for development environment only, due the possible secutity risk.
Elasticsearch cannot open log file: Permission denied
I installed Elasticsearch on CentOS using rpm and am encountering this error when I try to start it via systemctl start elasticsearch :
Feb 20 21:08:34 server.cberdata.org systemd[1]: Started Elasticsearch. Feb 20 21:08:34 server.cberdata.org elasticsearch[4226]: OpenJDK 64-Bit Server VM warning: Cannot open file /var/log/elasticsearch/gc.log due to Permission denied Feb 20 21:08:51 server.cberdata.org systemd[1]: elasticsearch.service: main process exited, code=exited, status=78/n/a Feb 20 21:08:51 server.cberdata.org systemd[1]: Unit elasticsearch.service entered failed state. Feb 20 21:08:51 server.cberdata.org systemd[1]: elasticsearch.service failed. Permissions
drwxr-xr-x 21 root root 4096 Feb 11 19:10 var drwxrwxr-- 12 root root 4096 Feb 20 21:00 log drwxrwxrwx 2 elasticsearch elasticsearch 4096 Feb 20 20:56 elasticsearch Permissions for /var/log/elasticsearch/gc.log
(which I manually created to see if that would help, but doing so had no effect on the error):
-rwxrwxrwx 1 elasticsearch elasticsearch 0 Feb 20 20:56 gc.log Setting /var/log permissions to drwxrwxrwx appears to fix the problem, but I’m hesitant to do that because it seems insecure and it results in these new errors:
/etc/cron.daily/logrotate: error: skipping "/var/log/exim_mainlog" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation. Am I correct that systemctl / systemd is running this service as the elasticsearch user? If it’s doing that, how can the owner of the file and its directory, with apparent read/write/execute permissions, not have permission to open that file?
Permission denied when logging on /var/log from a php script
I found my crontab scripts do not work as expected because they cannot write on /var/log. I tried executing command:
sudo /usr/bin/php /var/www/html/iPhone/inarrivo/php/rome/process.php >> /var/log/romeLoading.log 2>&1
I get no error whatsoever. What could be the issue? Please note Apache is not at stake: I am calling those scripts from the root crontab and from the shell with sudo as a test.
Permissions. It’s typical (and good practice) to not allow a webserver to run as a privileged user. If the info in the log is public, chmodd’ing the file to 0777 should allow it to work.
OK, and thank you for clarifying that in the question. So you’re running this from crontab . note that cron(8) doesn’t run as you, so its environment variables, etc., are not the same; in particular, paths can be at issue. I would start by verifying that you’re using the complete path to sudo. However, as you say this is root’s crontab . that’s interesting. What does a cronjob with simply «/usr/bin/env whoami» return? And, do you really need «sudo» if you’re running on the root crontab?
2 Answers 2
best guess: the user running the shell doesn’t have write access to /var/log/romeLoading.log , and the stdout redirect ( >> ) is redirected by the shell user, not the sudo user, thus the access denied on >> , but not on sudo touch . maybe try
sudo sh -c ‘/usr/bin/php /var/www/html/iPhone/inarrivo/php/rome/process.php >> /var/log/romeLoading.log 2>&1’
that should run sh as root, and have the root-sh do the redirect with root permissions. untested though.
and next time you want to post permissions for debugging, post the namei -l path/to/file output, it gives much more info than stating the single file itself when debugging permission issues, as the issue can be higher up than the file itself, like the folder its in, or the folder that the folder it’s in, is in, etc~ and namei gives you, recursively, detailed permission information on all of them.
Permision denied on log file
I want to be able to view log files from apache as regular user. I have set this files to 777 as root but still cannot view them as regular user, why is that?
#I have set permissions for everyone root@senior:/var/log/apache2# ls -l total 200 -rwxrwxrwx 1 root root 1951 Feb 27 23:07 access.log -rwxrwxrwx 1 root root 89508 Feb 27 23:07 error.log -rwxrwxrwx 1 root root 101601 Feb 27 23:06 other_vhosts_access.log #I have also set directory permission root@senior:/var/log# ls -l drw-rw-r-- 2 root adm 4096 Feb 27 23:08 apache2 kubi@senior:$ ls -l /var/log/apache2/ ls: cannot access /var/log/apache2/other_vhosts_access.log: Permission denied ls: cannot access /var/log/apache2/error.log: Permission denied ls: cannot access /var/log/apache2/access.log: Permission denied total 0 -. ? ? ? ? ? access.log -. ? ? ? ? ? error.log -. ? ? ? ? ? other_vhosts_access.log kubi@senior:/$ ls /var/log/apache2/error.log ls: cannot access /var/log/apache2/error.log: Permission denied 2 Answers 2
The directory should be 750 , not 664 . Also, you should add the user to the adm group. That’s actually largely the point of the adm group: reading logs.
Permissions on directories are a bit different than on files. To simplify a bunch, a directory is a list of names and addresses: the name is the filename, the address is the actual location of the file. The x permission controls access to this list: in order to look up the address of a specific file, you need the execute bit on its parent directory, and on that directory’s parent, etc. The r permission then controls listing files: If you have —x , you can access a file if you know its name, but you can’t ls . Lastly, w controls creating, renaming, and deleting files. So, in order to access a file, you always need the x bit.
Also: DON’T set the log files to 777. They should be 644 or 640, one of the two. Two reasons: one, they’re not executable, so the x bit should be off. Second, more importantly, normal users should never be writing to Apache log files, only reading. That’s a potential security hole in the server.
Permission Denied when writing log file
You need to fix permissions with the chmod command, like this: chmod 775 /home/shwetanka/logs/mysite/mysite.log .
Take a look at the owner of the file with ls -l /home/shwetanka/logs/mysite/mysite.log and make it writable to uwsgi . If the file isn’t owned by uwsgi , you’ll have to use the chown command.
Take a look at the username under which your service is running with ps aux | grep ‘uwsgi’ .
If the security isn’t so important to you at the moment, use chmod 777 /home/shwetanka/logs/mysite/mysite.log and that’s it. But that’s not the way how this is done.
The safest way to do this would be to check the owner and the group of the file and then change them if necessary and adjust the permissions accordingly.
If I have a file in /home/shwetanka/logs/mysite/mysite.log and the command ls -l /home/shwetanka/logs/mysite/mysite.log gives the following output:
-rw-rw-r-- 1 shwetanka shwetanka 1089 Aug 26 18:15 /home/shwetanka/logs/mysite/mysite.log it means that the owner of the file is shwetanka and the group is also shwetanka . Now let’s read the rwx bits. First group is related to the file owner, so rw- means that the file is readable and writable by the owner, readable and writeable by the group and readable by the others. You must make sure that the owner of the file is the service that’s trying to write something to it or that the file belongs to group of the service or you’ll get a permission denied error.
Now if I have a username uwsgi that’s used by the USWGI service and want the above file to be writable by that service, I have to change the owner of the file, like this:
chown uwsgi /home/shwetanka/logs/mysite/mysite.log . Since the write bit for the owner (the first rwx group) is already set to 1 , that file will now be writable by the UWSGI service. For any further questions, please leave a comment.