Laravel daily log created with wrong permissions

Question

I have a script that I run using php artisan (with root user), and sometimes it causes the daily log file to be created before the apache www-data user does - which means that when a real user uses my web application, I get the folder permission error:

Failed to open stream: Permission denied

I change the permissions back to www-data everytime but I want to solve this by having the log file always created with the correct permissions.

I've considered creating a cron job that creates the file or touches it to make sure it has the right permission everyday, but I'm looking for a better solution that doesn't rely on another script.

We've also considered wrapping php artisan in another script to make sure that it is always run with the www-data credentials, but somethings that we want to do are actually root procedures that apache should not be allowed to do.

Any more suggestions?

Centrepiece

Setup a cron job to touch a new log file at midnight every day (under the correct user, of course). – Cottony

@BenHarold Thanks, we've considered that but I'd rather not involve more scripts. – Centrepiece

In that case you'll need to run php artisan as the user that you want to create the log file. – Cottony

@BenHarold Again thanks, we've considered that as well, which is probably the best way to go, but I've updated the question to explain why this also isn't ideal. – Centrepiece

What worked for me was to execute the cron as the www-data user with sudo crontab -u www-data -e – Engenia

you could also simply change the owner to the script owner in your artisan command, see https://mcmap.net/q/87256/-laravel-daily-log-created-with-wrong-permissions – Nakia

Answer 1

IMPORTANT This answer is incompatible with laravel 5.5+. Please see this answer: Custom (dynamic) log file names with laravel5.6

Let's start with what is constant.

You have a php artisan command, run by root.

It is safe to assume that this command is executed daily.

Solution No 1:

Given that the user that creates the files is the one that has the permission to write to it by default, we can separate the logs by user as such:

App/start/global.php

/*
|--------------------------------------------------------------------------
| Application Error Logger
|--------------------------------------------------------------------------
|
| Here we will configure the error logger setup for the application which
| is built on top of the wonderful Monolog library. By default we will
| build a basic log file setup which creates a single file for logs.
|
*/

Log::useDailyFiles(storage_path().'/logs/laravel-'.posix_getpwuid(posix_geteuid())['name'].'.log');

If your www-data user were to create an error log, it would result in: storage/logs/laravel-www-data-2015-4-27.log.

If your root user were to create an error log, it would result in: storage/logs/laravel-root-2015-4-27.log.

Solution No 2:

Change the log used by your artisan command, in your php script.

In your run() function, add this line at the start:

Log::useFiles(storage_path().'/logs/laravel-'.__CLASS__.'-'.Carbon::now()->format('Y-m-d').'.log');

If your class's name is ArtisanRunner, then your log file will be:

storage/logs/laravel-ArtisanRunner-2015-4-27.log.

Conclusion: Solution number 1 is better, given that it delineates your logs by user, and hence no errors will occur.

EDIT: As pointed out by jason, get_current_user() returns the script's owner name. Hence, for solution no.1 to apply, chown your artisan class files to the required username.

Brewhouse

Please note that get_current_user() returns the owner of the current PHP script (according to php.net) and not the user who is currently running the script. I use php_sapi_name() instead, which gives the name of the php handler (apache or cli, for example) which will tend to be run as different users. – Pucka

Can I make the suggestion of using both users name executing the script and php_sapi_name in combination as it's possible for many users to execute Laravel from the CLI e.g. a few DBAs access your server or you may want the Laravel CRON to run as apache.You can get the process name executing this script using posix_getpwuid(posix_geteuid())['name']; See my full post below. – Arrange

This needs to be updated for latest Laravel versions: v5+ – Arrange

@ShankarSBavan This is incompatible for laravel 5.5+ – Brewhouse

@ShankarSBavan Check this answer for a compatible solution: #50305686 – Brewhouse

Answer 2

Laravel version 5.6.10 and later has support for a permission element in the configuration (config/logging.php) for the single and the daily driver:

    'daily' => [
        'driver' => 'daily',
        'path' => storage_path('logs/laravel.log'),
        'level' => 'debug',
        'days' => 7,
        'permission' => 0664,
    ],

No need to juggle with Monolog in the bootstrap script.

Specifically, support was added in https://github.com/laravel/framework/commit/4d31633dca9594c9121afbbaa0190210de28fed8.

Azpurua

this should be in the official doc ! – Candancecandela

apostrophes are missing in this answer. It should be 'permission' => '0664'. Then this answer is perfectly fine! – Degrease

@Degrease Nope - this is just a wrapper for Monologs stream handler which accepts an int for permissions. Monolog wraps php.net/manual/en/function.chmod.php - note that a leading 0 is required to make sure it is an octal value – Samurai

This answer save my day! Take care to put the apostrophes missing in this answer. – Disgust

'permission' => 0664 works for me (without quotes) – Jarlathus

This doesn't solve the problem, as it doesn't change the owner nor the group of the file. Both are still root and when a script run by www-data wants to write into this file, it is still not permitted to do that. The answer of @mysteryos solves the problem (for me at least). – Depositary

@Depositary if your log file is being created with 'root' as the owner of the file, that likely signals that you have larger issues in terms of how your webserver is setup – Huffish

@kjones, in general you are right, but the php cli (which sometimes creates a logfile) is run by the root user and has nothing to do with the webserver. It is the same situation as for the question author: "We've also considered wrapping php artisan in another script to make sure that it is always run with the www-data credentials, but somethings that we want to do are actually root procedures that apache should not be allowed to do". – Depositary

gotcha @Friedrich, I see now given the context – Huffish

Please note that writing 0777 in quotes, created the log file in -r----x--t 1 user user 151982 Feb 10 13:25 laravel-2020-02-10.log which will raise some serious issues. So please do not mention any quotes (since the same is mentioned in their official docs). After removing quotes, I got -rwxrwxrwx 1 user user 471141 Feb 10 13:29 laravel-2020-02-10.log which is the required one. P.S Giving 777 permissions in production is not a good practice. – Gardner

this should be the accepted answer – Mushy

without quotes it is an octal number, which is how unix/linux works – Mushy

before applying this answer my error message was "The stream or file ***.log\" could not be opened: failed to open stream: Permission denied", after applying the answer the error message changed to: "The stream or file ***.log\" could not be opened: chmod(): Operation not permitted", – Nutbrown

Answer 3

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);
});

There are lots of other Handlers that you can use instead, of course.

Dasie

I really like this answer because 1) it's updated to 5.1 and 2) uses a method in the docs to extend the log behavior. – Maggie

Excellent, the extra forward-flash is not needed but still works. It should read... $filename = storage_path('logs/laravel-'.php_sapi_name().'.log'); – Arrange

Can I make the suggestion of using both users name executing the script and php_sapi_name in combination as it's possible for many users to execute Laravel from the CLI e.g. a few DBAs access your server or you may want the Laravel CRON to run as apache.You can get the process name executing this script using posix_getpwuid(posix_geteuid())['name']; See my full post below. – Arrange

How to use it in Laravel 5.6? Because Laravel 5.6 has a brand new Logging system. – Rourke

Is this applicable on Laravel 5.3 also? Please, reply! – Backandforth

Answer 4

For such purposes you should use advanced ACL on your files and directories. setfacl would be your answer here. If you want to give www-data user permissions to write on root's files in specific directory, you can do it like this:

setfacl -d -m default:www-data:you-chosen-group:rwx /my/folder

After issuing this you're setting permissions to rwx for www-data user on all files in /my/folder/ no matter who created those. Please, see this and this question for reference. Also, you can check docs for setfacl.

Let me know if this helps.

Deipnosophist

The following command worked for me: setfacl -d -m g:www-data:rw /full/path/to/laravel/storage/logs followed by php artisan cache:clear and composer dump-autoload. – Lachellelaches

Answer 5

I had this worked very simple way:

I ran into the same problem on Laravel 5.6

In config/logging.php I just updated daily channel's path value with php_sapi_name() in it.

This creates seperate durectory for different php_sapi_name and puts log file with the time stamp into their perticular directory.

'daily' => [
            'driver' => 'daily',
            'path' => storage_path('logs/' . php_sapi_name() . '/laravel.log'),
            'level' => 'debug',
            'days' => 7,
        ]

So for me,

• Log files are created under fpm-fcgi directory: Logs from website, owner: www-data
• Log files are created under cli directory: from the artisan command(cronjob). owner: root

More info on Laravel 5.6 logging: https://laravel.com/docs/5.6/logging

Here is my config/logging.php file:

<?php

return [
    /*
    |--------------------------------------------------------------------------
    | Default Log Channel
    |--------------------------------------------------------------------------
    |
    | This option defines the default log channel that gets used when writing
    | messages to the logs. The name specified in this option should match
    | one of the channels defined in the "channels" configuration array.
    |
    */
    'default' => env('LOG_CHANNEL', 'stack'),
    /*
    |--------------------------------------------------------------------------
    | Log Channels
    |--------------------------------------------------------------------------
    |
    | Here you may configure the log channels for your application. Out of
    | the box, Laravel uses the Monolog PHP logging library. This gives
    | you a variety of powerful log handlers / formatters to utilize.
    |
    | Available Drivers: "single", "daily", "slack", "syslog",
    |                    "errorlog", "custom", "stack"
    |
    */
    'channels' => [
        'stack' => [
            'driver' => 'stack',
            'channels' => ['daily'],
        ],
        'single' => [
            'driver' => 'single',
            'path' => storage_path('logs/laravel.log'),
            'level' => 'debug',
        ],
        'daily' => [
            'driver' => 'daily',
            'path' => storage_path('logs/' . php_sapi_name() . '/laravel.log'),
            'level' => 'debug',
            'days' => 7,
        ],
        'slack' => [
            'driver' => 'slack',
            'url' => env('LOG_SLACK_WEBHOOK_URL'),
            'username' => 'Laravel Log',
            'level' => 'critical',
        ],
        'syslog' => [
            'driver' => 'syslog',
            'level' => 'debug',
        ],
        'errorlog' => [
            'driver' => 'errorlog',
            'level' => 'debug',
        ],
    ],
];

Wormseed

nice ... ur solution is cleaner .. im testing it now – Pyszka

As has been pointed out in another comment, logs are only a part of the story. There are compiled views, data caches, pre-cached source code, any of which my be created as local files by either the web or the cli user. – Pucka

This does not work if you cache the config using artisan config:cache, since it will create a config cache using the cli SAPI which will be used for both CLI and web requests. – Erosive

This works for me, tried get_current_user doesn't work, but php_sapi_name do work (although it seems uglier) – Malissamalissia

I think this is the fastest and best way. Modifying the configuration don't modify the basic structure of Laravel, just configuration. – Quinze

Answer 6

For me this issue was much more than log permissions...I had issues with anything related to the bootstrap/cache and storage folders where one user would create a file/folder and the other would be unable to edit/delete due to the standard 644 and 755 permissions.

Typical scenarios are:

• The bootstrap/cache/compiled.php file being created by the apache user but being uneditable by the composer user when performing the composer install command

• The apache user creating cache which cannot be cleared using the composer user

• The dreaded log race conditions described above.

The dream is that no matter which user creates the file/folder, the other users that need to access have exactly the same permissions as the original author.

TL;DR?

Here's how it's done.

We need to create a shared user group called laravel, the group consists of all the users that need access to the storage and bootstrap/cache directories. Next we need to ensure newly created files and folders have the laravel group and 664 and 775 permissions respectively.

It's easy doing this for existing files/directories, but a little magic is needed to tweak the default file/folder creating rules...

## create user group
sudo groupadd laravel

## add composer user to group
sudo gpasswd -a composer-user laravel

## add web server to group
sudo gpasswd -a apache laravel

## jump to laravel path
sudo cd /path/to/your/beautiful/laravel-application

## optional: temporary disable any daemons that may read/write files/folders
## For example Apache & Queues

## optional: if you've been playing around with permissions
## consider resetting all files and directories to the default
sudo find ./ -type d -exec chmod 755 {} \;
sudo find ./ -type f -exec chmod 644 {} \;

## give users part of the laravel group the standard RW and RWX
## permissions for the existing files and folders respectively
sudo chown -R :laravel ./storage
sudo chown -R :laravel ./bootstrap/cache
sudo find ./storage -type d -exec chmod 775 {} \;
sudo find ./bootstrap/cache -type d -exec chmod 775 {} \;
sudo find ./storage -type f -exec chmod 664 {} \;
sudo find ./bootstrap/cache -type f -exec chmod 664 {} \;


## give the newly created files/directories the group of the parent directory 
## e.g. the laravel group
sudo find ./bootstrap/cache -type d -exec chmod g+s {} \;
sudo find ./storage -type d -exec chmod g+s {} \;

## let newly created files/directories inherit the default owner 
## permissions up to maximum permission of rwx e.g. new files get 664, 
## folders get 775
sudo setfacl -R -d -m g::rwx ./storage
sudo setfacl -R -d -m g::rwx ./bootstrap/cache

## Reboot so group file permissions refresh (required on Debian and Centos)
sudo shutdown now -r

## optional: enable any daemons we disabled like Apache & Queues

Purely for debugging purposes I found splitting the logs out into both cli/web + users was beneficial so I modified Sam Wilson's answer slightly. My use case was the queue ran under it's own user so it helped distinguish between the composer user using the cli (e.g. unit tests) and the queue daemon.

$app->configureMonologUsing(function(MonologLogger $monolog) {
     $processUser = posix_getpwuid(posix_geteuid());
     $processName= $processUser['name'];

     $filename = storage_path('logs/laravel-'.php_sapi_name().'-'.$processName.'.log');
     $handler = new MonologHandlerRotatingFileHandler($filename);
     $monolog->pushHandler($handler);
}); 

Arrange

This is very good. Is your configureMonologUsing code still necessary though, once you've run the setfacl commands? – Swec

Answer 7

One non-Laravel way to make this work is to simply executure your cronjob as www-data.

eg https://askubuntu.com/questions/189189/how-to-run-crontab-as-userwww-data

/etc/crontab

*/5 * * * * www-data php /var/www/public/voto_m/artisan top >/dev/null 2>&1

Injured

Answer 8

Laravel 5.1

In our case we wanted to create all log files so that everything in the deploy group had read/write permissions. Therefore, we needed to create all new files with 0664 permissions, opposed to the 0644 default.

We also added a formatter to add newlines for better readability:

$app->configureMonologUsing(function(Monolog\Logger $monolog) {
    $filename = storage_path('/logs/laravel.log');
    $handler = new Monolog\Handler\RotatingFileHandler($filename, 0, \Monolog\Logger::DEBUG, true, 0664);
    $handler->setFormatter(new \Monolog\Formatter\LineFormatter(null, null, true, true));
    $monolog->pushHandler($handler);
});

Also it's possible to combine this with the accepted answer

$app->configureMonologUsing(function(Monolog\Logger $monolog) {
    $filename = storage_path('/logs/laravel-' . php_sapi_name() . '.log');
    $handler = new Monolog\Handler\RotatingFileHandler($filename, 0, \Monolog\Logger::DEBUG, true, 0664);
    $handler->setFormatter(new \Monolog\Formatter\LineFormatter(null, null, true, true));
    $monolog->pushHandler($handler);
});

Indiscrete

Answer 9

Laravel 5.5

Add this code to bootstrap/app.php:

$app->configureMonologUsing(function (Monolog\Logger $monolog) {
    $filename = storage_path('logs/' . php_sapi_name() . '-' . posix_getpwuid(posix_geteuid())['name'] . '.log');
    $monolog->pushHandler($handler = new Monolog\Handler\RotatingFileHandler($filename, 30));
    $handler->setFilenameFormat('laravel-{date}-{filename}', 'Y-m-d');
    $formatter = new \Monolog\Formatter\LineFormatter(null, null, true, true);
    $formatter->includeStacktraces();
    $handler->setFormatter($formatter);
});

• It will store files like this: laravel-2018-01-27-cli-raph.log and laravel-2018-01-27-fpm-cgi-raph.log which is more readable.
• New lines are preserved (as of default Laravel behavior)
• It works with Laravel Log Viewer

Laravel 5.6

You have to create a class for your logger:

<?php

namespace App;

use Monolog\Logger as MonologLogger;

class Logger {
    public function __invoke(array $config)
    {
        $monolog = new MonologLogger('my-logger');
        $filename = storage_path('logs/' . php_sapi_name() . '-' . posix_getpwuid(posix_geteuid())['name'] . '.log');
        $monolog->pushHandler($handler = new \Monolog\Handler\RotatingFileHandler($filename, 30));
        $handler->setFilenameFormat('laravel-{date}-{filename}', 'Y-m-d');
        $formatter = new \Monolog\Formatter\LineFormatter(null, null, true, true);
        $formatter->includeStacktraces();
        $handler->setFormatter($formatter);
        return $monolog;
    }
}

Then, you have to register it in config/logging.php:

'channels' => [
    'custom' => [
        'driver' => 'custom',
        'via' => App\Logging\CreateCustomLogger::class,
    ],
],

Same behavior as for 5.5:

• It will store files like this: laravel-2018-01-27-cli-raph.log and laravel-2018-01-27-fpm-cgi-raph.log which is more readable.
• New lines are preserved (as of default Laravel behavior)
• It works with Laravel Log Viewer

Entophyte

Best answer! Kudos – Sirocco

Answer 10

Add something like the following to the start of your app/start/artisan.php file (this is with Laravel 4):

// If effectively root, touch the log file and make sure it belongs to www-data
if (posix_geteuid() === 0) {
    $file = storage_path() . '/logs/laravel.log';
    touch($file);
    chown($file, 'www-data');
    chgrp($file, 'www-data');
    chmod($file, 0664);
}

Adjust the path if the daily log file you mention is not the standard Laravel log file. You also may not want to change the group or set the permissions as I am doing here. The above sets the group to www-data and sets group write permissions. I've then added my regular user to the www-data group so that running artisan commands as my regular user can still write to the log.

A related tweak is to put the following at the start of your app/start/global.php file:

umask(0002);

If you do this the chmod line above becomes moot. With the umask set to this, any new files PHP (and therefore Laravel) makes will have their permissions masked only so that "other" users won't have write permissions. This means directories will start as rwxrwxr-x and files as rw-rw-r--. So if www-data is running PHP, any cache and log files it makes will be writeable by default by anyone in that user's main group, which is www-data.

Afterword

Answer 11

(Laravel 5.6) I recently ran into the same problem and I simply set a scheduled command to run in /app/Console/Kernel.php.

$schedule->exec('chown -R www-data:www-data /var/www/**********/storage/logs')->everyMinute();

I know it's a little bit of overkill, but it works like a charm and haven't had any issues since.

Sanskrit

It works ? Yep, but Is best practice ? I think not. – Isopiestic

I would say very much an overkill.... and if you were to do something like this, why don't just do it directly in the cron? – Glaudia

Answer 12

Laravel 5.4

\Log::getMonolog()->popHandler(); \Log::useDailyFiles(storage_path('/logs/laravel-').get_current_user().'.log');

add to boot function in AppServiceProvider

Houlberg

Is this applicable in Laravel 5.3 also? – Backandforth

Answer 13

Laravel 5.8

Laravel 5.8 lets you set the log name in config/logging.php.

So using previous answers and comments, if you want to name you log using both the actual posix user name AND the php_sapi_name() value, you only need to change the log name set. Using the daily driver allows log rotation that runs per user / api combination which will ensure that the log is always rotated by an account that can modify the logs.

I also added a check for the posix functions which may not exist on your local environment, in which case the log name just defaults to the standard.

Assuming you are using the default log channel 'daily', you can modify your 'channels' key like so:

# config/logging.php
'channels' => [
    ...
    'daily' => [
        'driver' => 'daily',
        'path'   => storage_path(
            function_exists('posix_getpwuid') 
            && function_exists('posix_geteuid')
                ? 'logs/laravel'
                    . '-' . php_sapi_name()
                    . '-' . posix_getpwuid(posix_geteuid())['name'] 
                    . '.log'
                : 'logs/laravel.log'),
        'level'  => 'debug',
        'days'   => 15,
    ],
    ...

This will result in a log name that should be unique to each combination such as laravel-cli-sfscs-2019-05-15.log or laravel-apache2handler-apache-2019-05-15.log depending on your access point.

Southeastwardly

This helped me! Of course, don't forget to run php artisan cache:clear to apply changes. – Adapter

@Adapter You are incorrect, that command does not apply changes to config. php artisan cache:clear clears the application cache, those are data manually cached and is unrelated to the config. However, in the event you've cached your config with php artisan config:cache, then yes you must clear your config cache when you make changes, using php artisan config:clear. This would be the case for config/logging.php as in the answer above. – Southeastwardly

Answer 14

You could simply change the permission of the log file in your artisan command:

$path = storage_path('log/daily.log');
chown($path, get_current_user());

where get_current_user() will return the user of the current script.

In other words, daily.log will always have www-data as its owner, even if you initialize the script as root user.

Nakia

Is this applicable for Laravel 5.3 also? – Backandforth

@Backandforth yes get_current_user() is a php native function – Nakia

Answer 15

If you're using Laravel Envoyer, here is a possible fix using ACL in Linux:

1. First, run the following script with root permissions on the server:

In both scripts you'll need to replace the variables as instructed below:

• {{MASTER_PATH}}: The path to your virtual hosts directory (eg. the folder > containing your application(s)).
• {{WEB_SERVER_USER}}: The user your web-server uses.
• {{DEPLOYMENT_USER}}: The user your deployment script is run by.

#!/bin/bash

DIRS="storage current/bootstrap/cache"
MASTER_PATH={{MASTER_PATH}}

if [ -d $MASTER_PATH ]; then 
    cd $MASTER_PATH
    for p in `ls $MASTER_PATH`; do 
        if [ -d $MASTER_PATH/$p ]; then     
        cd $MASTER_PATH/$p
            echo "Project: $p -> $MASTER_PATH/$p"
            for i in $DIRS; do 
                echo "- directory: $i" 
                if [ -d $i ]; then 
                    echo "-- checking ACL..."
                    HAS_ACL=`getfacl -p $i | grep "^user:{{WEB_SERVER_USER}}:.*w" | wc -l`
                    if [  $HAS_ACL -eq 0 ]; then 
                        echo "--- applying $i"
                        setfacl -L -R -m u:{{WEB_SERVER_USER}}:rwX -m u:{{DEPLOYMENT_USER}}:rwX $i
                        setfacl -dL -R -m u:{{WEB_SERVER_USER}}:rwX -m u:{{DEPLOYMENT_USER}}:rwX $i
                    else
                        echo "--- skipping $i"
                    fi
                fi
            done
        echo "--------------"
        fi
    done
else
    echo "No $MASTER_PATH - skipping overall"
fi

2. Set up the following deployment hook on envoyer under "Activate New Release" > "Before This Action

PROJECT_DIRS="storage"
RELEASE_DIRS="bootstrap/cache"
 
cd {{ project }}
 
for i in $PROJECT_DIRS; do
  if [ -d $i ]; then
    HAS_ACL=`getfacl -p $i | grep "^user:{{WEB_SERVER_USER}}:.*w" | wc -l`
    if [  $HAS_ACL -eq 0 ]; then
      echo "ACL set for directory {{project}}/$i"
      setfacl -L -R -m u:{{WEB_SERVER_USER}}:rwX -m u:{{DEPLOYMENT_USER}}:rwX $i
      setfacl -dL -R -m u:{{WEB_SERVER_USER}}:rwX -m u:{{DEPLOYMENT_USER}}:rwX $i
    fi
  fi
done
 
cd {{ release }}
 
for i in $RELEASE_DIRS; do
  if [ -d $i ]; then
    HAS_ACL=`getfacl -p $i | grep "^user:{{WEB_SERVER_USER}}:.*w" | wc -l`
    if [  $HAS_ACL -eq 0 ]; then
      echo "ACL set for directory {{project}}/$i"
      setfacl -L -R -m u:{{WEB_SERVER_USER}}:rwX -m u:{{DEPLOYMENT_USER}}:rwX $i
      setfacl -dL -R -m u:{{WEB_SERVER_USER}}:rwX -m u:{{DEPLOYMENT_USER}}:rwX $i
    fi
  fi
done

3. Redeploy your application

Now redeploy your appliaction, and it should work going forward.

Note: The script defined in 1. should be run every time you add a new project to the machine.

Stadler

Answer 16

The best way I found is that fideloper suggest, http://fideloper.com/laravel-log-file-name, you can set laravel log configuration without touch Log class. Have differents names for Console programs and Http programs, I think, is the best solution.

Middlings

Answer 17

This solution will definately work on Laravel V5.1 - V6.x

Reasons for this error:

• There mainly cause due to permission issues
• Environment variables not found or .env file not found on your root directory
• PHP extensions problem
• Database problem

Fix:

• Set the correct permissions:
  • Run these commands (Ubuntu/Debian)

find /path/to/your/root/dir/ -type f -exec chmod 644 {} \;
find /path/to/your/root/dir/ -type d -exec chmod 755 {} \;

chown -R www-data:www-data /path/to/your/root/dir/

chgrp -R www-data storage bootstrap/cache
chmod -R ug+rwx storage bootstrap/cache

• If .env file doesn't exist, create one by touch .env and paste your environment variables and then run

   php artisan key:generate
   php artisan cache:clear
   php artisan config:clear
   composer dump-autoload
   php artisan migrate //only if not already migrated

Jopa

Answer 18

cd /path/to/project
chown -R www-data:root .
chmod -R g+s .

Expansible

This is terrible advice, do not do this – Suchta