log file permission problem

First of all why do you want to change the permission of the log file? You want to read it right? Not execute it...

Take a look at this: http://laravel.com/docs/5.1/errors#configuration As it's stated in the documentation you can configure it to a daily file like you have or to a single file or just log the errors and so on

@bobbybouwmann Thanks for your reply. Because I got this error said Permission denied from nginx. I have to chmod 777 log file, then everything works fine.

2015/07/03 12:16:04 [error] 835#0: *7782 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught exception 'UnexpectedValueException' with message 'The stream or file "/var/www/rsct/releases/20150703025221/storage/logs/laravel-2015-07-03.log" could not be opened: failed to open stream: Permission denied' in /var/www/rsct/releases/20150703025221/bootstrap/cache/compiled.php:13005

I think you should use this command though: chmod -R 755 app/storage The 777 is bad practice ;)

Sorry for hijacking thread. But I run into this problem all the time and I'm not quite sure how to get rid of it.

It seems there are 2 ways log files can be created:

1. Via the web application. You access the application from the browser and some code wants to write something to the log file. If the log file is not there (e.g. because you use daily logs and nothing has been logged yet) the owner of the log file will be the webserver user, _www in my case.

2. Via artisan. I use artisan a lot, generate a controller, a migration whatever. If some code that has been triggered via an artisan call throws an exception then artisan wants to write that exception to the log. If the logfile is not there, it will create the logfile but with the user that executed the artisan command as the owner of the logfile.

@1 creates a logfile with permissions 644 and user _www If artisan needs to write to the log now it has no right to do so and throws an exception.

@2 creates a logfile with permissions 644 and user myMacUser If the webapplication needs to write to the log now it has no right to do so and throws an exception.

How do you get out of this dilemma (without setting the logfile to single and give everything permission to write to it) ?

I connection to this thread.

That situation - stops my live projects..

If log created from cli, full web site is stop work.

and another, if logs created by www user - i unable use artisan commands. For resolve use artisan command need chmod 777 from root user.

How to true way for resolve this problem?

ps: Daily logs - comfortable log type...

I had the same issue with Centos7 ... I tried EVERYTHING. Finally, I found a post on stackoverflow suggesting it could be selinux. I disabled selinux and it worked!

I used this and solved my problem (found in answer on StackOverflow post http://stackoverflow.com/questions/27674597/laravel-daily-log-created-with-wrong-permissions ).

It says Laravel 5.1, but I am using 5.2.41 and works great.

For Laravel 5.1 I use the following towards the bottom of bootstrap/app.php (as mentioned in the docs):

/**
 * Configure Monolog.
 */
$app->configureMonologUsing(function(Monolog\Logger $monolog) {
    $filename = storage_path('logs/laravel-'.php_sapi_name().'.log');
    $handler = new Monolog\Handler\RotatingFileHandler($filename);
    $monolog->pushHandler($handler);
});

Now I am getting two log files: one for web (apache) and one for cli (as root)

[root@centos6 laravel]#  ll storage/logs/
total 1896
-rw-r--r-- 1 root   root      2410 Jul 26 14:29 laravel-cli-2016-07-26.log
-rw-r--r-- 1 apache apache 1930076 Jul 26 14:27 laravel.log

@kobear Your solution will mostly solve my current issue to some extent.

Just to add, I am having similar issue and it seems to be selinux causing. It just doesn't allow php (laravel) create a log file even though file permissions are set to 775 and nginx, php-fpm belongs to same group.

@jacobfogg

"I had the same issue with Centos7 ... I tried EVERYTHING. Finally, I found a post on stackoverflow suggesting it could be selinux. I disabled selinux and it worked!"

Can you send stackoverflow link for the solution?

The other solutions seemed to convoluted for me, so I resorted to switching from a daily log file to a single one, to which I assigned the correct access permissions. Since no new files are created by www-data, I don't have to chmod them everyday.

This, however, is fine for local development. In production, I would prefer storing the logs into something like MongoDB, SQLite or even a MySQL table.

If you make /var/www writeable by its group and add the user to the group, that user will not have to use sudo. Try this:

sudo adduser <username> www-data
sudo chown -R www-data:www-data /var/www
sudo chmod -R g+rwX /var/www

The user should then be able to edit /var/www/ files without hassle.

The first line adds the user to the www-data group, the second line clears up any files with messed up ownership, and the third makes it so that all users who are members of the www-data group can read and write all files in /var/www.

If you are logged in as you need to log out and log back in for the group membership to take effect.

see https://askubuntu.com/questions/19898/whats-the-simplest-way-to-edit-and-add-files-to-var-www

The problem arose for me when I started writing debug messages to the log from a custom artisan command.

@kobear This solution worked perfectly for me, however, there are no line breaks in the logs. The entire error message is on one line if you look at it using nano, or if I tail it in the console, it's one big jumbled mess. Do you have an idea how to fix this?

@jacobfogg Your suggestion fixed my issue at least (on Centos 7).

The error did not go away even though both permissions and ownerships were set correctly. Turns out it was selinux that was the culprit.

See https://linuxhint.com/how-to-disable-selinux-on-centos-7/

An old thread, I know, but don't use 777 permissions for log files, since they do not need to be executable. Use 666if it needs to be readable and writable by multiple users that are not in the same group.

I found this answer in Stack Overflow, it's really helpful https://stackoverflow.com/a/49379249/6400480

I've always used ACL when having to deal with the local user who 'owns the app' and the web server user

Assuming your webserver user runs as www-data I run this on my local linux user

setfacl -d -R -m u:$USER:rwx -m g:www-data:rwx storage/   
setfacl -d -R -m u:$USER:rwx -m g:www-data:rwx bootstrap/cache/

This helped me to understand the issue and what was actually happening. It's been recurring on and off for 2 years on prod servers and I feel like we just actually figured it out.

Envoyer was adding a log file with itself as the user, which the www-data user couldn't access. Envoyer was a part of the www-data group.

By changing the permissions to allow group write access, this issue went away!

THANK YOU!

In case someone has this issue as me:

I thought I have set the right users and groups, and only 777 worked. I was pulling my hair as to why this happening, and then I realized if 777 allows writing to a directory it means the webserver user is not in the group!

checked the log:

Server/Request Data
USER	
"registration"
HOME	
"/home/registration"
SCRIPT_NAME	
"/index.php"

while I was sure that the user running the server is reg or apache as I set, registration was the user as it was set in Cpanel, Webmin, or Plesk.

DOUBLE-CHECK WHAT IS THE USER IS ACTUALLY WRITING :) hope it helps someone