Ich habe ein Skript, das ich mit PHP Artisan (mit Root- Benutzer) ausführe , und manchmal wird die tägliche Protokolldatei erstellt, bevor der Apache - Benutzer www-data dies tut. Das bedeutet, dass ich bekomme, wenn ein echter Benutzer meine Webanwendung verwendet der Ordnerberechtigungsfehler:

Fehler beim Öffnen des Streams: Berechtigung verweigert

Ich ändere die Berechtigungen jedes Mal wieder auf www-data , möchte dies jedoch lösen, indem die Protokolldatei immer mit den richtigen Berechtigungen erstellt wird.

Ich habe überlegt, einen Cron-Job zu erstellen, der die Datei erstellt oder berührt, um sicherzustellen, dass sie jeden Tag die richtige Berechtigung hat, aber ich suche nach einer besseren Lösung, die nicht auf einem anderen Skript basiert.

Wir haben auch darüber nachgedacht, PHP Artisan in ein anderes Skript zu packen, um sicherzustellen, dass es immer mit den Anmeldeinformationen für www-Daten ausgeführt wird. Wir möchten jedoch tatsächlich Root- Prozeduren ausführen, die Apache nicht ausführen darf.

Noch Vorschläge?

Beginnen wir mit dem, was konstant ist.

Sie haben einen php artisanBefehl, der von ausgeführt wird root.

Es ist davon auszugehen, dass dieser Befehl täglich ausgeführt wird.

Lösung Nr. 1:

Da der Benutzer, der die Dateien erstellt, standardmäßig die Berechtigung zum Schreiben hat, können wir die Protokolle nach Benutzern als solche trennen:

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-'.get_current_user().'.log');

Wenn Ihr WWW-Datenbenutzer ein Fehlerprotokoll erstellen würde, würde dies zu Folgendem führen : storage/logs/laravel-www-data-2015-4-27.log.

Wenn Ihr Root- Benutzer ein Fehlerprotokoll erstellen würde, würde dies zu Folgendem führen : storage/logs/laravel-root-2015-4-27.log.

Lösung Nr. 2:

Ändern Sie das von Ihrem Handwerkerbefehl verwendete Protokoll in Ihrem PHP-Skript.

Fügen Sie in Ihrer run()Funktion diese Zeile am Anfang hinzu:

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

Wenn der Name Ihrer Klasse lautet ArtisanRunner, lautet Ihre Protokolldatei:

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

Schlussfolgerung: Lösung Nummer 1 ist besser, da sie Ihre Protokolle nach Benutzer abgrenzt und daher keine Fehler auftreten.

BEARBEITEN: Gibt get_current_user()den Besitzernamen des Skripts zurück , wie von Jason hervorgehoben . Damit die Lösung Nr. 1 angewendet werden kann, müssen chownIhre Handwerkerklassendateien den erforderlichen Benutzernamen haben.

Laravel Version 5.6.10 und höher unterstützt ein permissionElement in der Konfiguration ( config/logging.php) für den singleund den dailyTreiber:

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

Sie müssen im Bootstrap-Skript nicht mit Monolog jonglieren.

Insbesondere wurde Unterstützung in https://github.com/laravel/framework/commit/4d31633dca9594c9121afbbaa0190210de28fed8 hinzugefügt .

Für Laravel 5.1 verwende ich Folgendes unten bootstrap/app.php(wie in den Dokumenten erwähnt ):

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

Es gibt natürlich viele andere Handler, die Sie stattdessen verwenden können.

Für solche Zwecke sollten Sie erweiterte ACL für Ihre Dateien und Verzeichnisse verwenden. setfaclwäre deine Antwort hier. Wenn Sie den Benutzern von www-data die Berechtigung zum Schreiben in die Root- Dateien in einem bestimmten Verzeichnis erteilen möchten , können Sie dies folgendermaßen tun:

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

Nachdem Sie dies erteilt haben, legen Sie die Berechtigungen rwxfür den Benutzer von www-data für alle Dateien fest, /my/folder/unabhängig davon, wer diese erstellt hat. Bitte lesen Sie diese und diese Frage als Referenz. Sie können auch Dokumente aufsetfacl überprüfen .

Lassen Sie mich wissen, ob das hilft.

Ich hatte das sehr einfach gemacht:

Ich bin auf Laravel 5.6 auf dasselbe Problem gestoßen

In config/logging.phpIch habe gerade den Pfadwert des täglichen Kanals mit aktualisiert php_sapi_name().

Dadurch wird ein separates Verzeichnis für verschiedene php_sapi_name erstellt und die Protokolldatei mit dem Zeitstempel in ihrem jeweiligen Verzeichnis abgelegt.

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

Also für mich,

• Protokolldateien werden im fpm-fcgiVerzeichnis erstellt: Protokolle von der Website,owner: www-data
• Protokolldateien werden unter cliVerzeichnis erstellt: über den Befehl handwerker (cronjob).owner: root

Weitere Informationen zur Laravel 5.6-Protokollierung: https://laravel.com/docs/5.6/logging

Hier ist meine config/logging.phpDatei:

<?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',
        ],
    ],
];

Für mich war dieses Problem viel mehr als Protokollberechtigungen ... Ich hatte Probleme mit irgendetwas im Zusammenhang mit den Bootstrap- / Cache- und Speicherordnern, bei denen ein Benutzer eine Datei / einen Ordner erstellen und der andere aufgrund des Standards nicht bearbeiten / löschen konnte 644 und 755 Berechtigungen.

Typische Szenarien sind:

• Die Datei bootstrap / cache / compiled.php wird vom Apache-Benutzer erstellt, kann jedoch vom Composer-Benutzer beim Ausführen des Composer-Installationsbefehls nicht bearbeitet werden

• Der Apache-Benutzer erstellt einen Cache, der mit dem Composer-Benutzer nicht gelöscht werden kann

• Die oben beschriebenen gefürchteten Log Race Bedingungen.

Der Traum ist, dass unabhängig davon, welcher Benutzer die Datei / den Ordner erstellt, die anderen Benutzer, auf die zugegriffen werden muss, genau die gleichen Berechtigungen wie der ursprüngliche Autor haben.

TL; DR?

Hier ist, wie es gemacht wird.

Wir müssen eine gemeinsam genutzte Benutzergruppe namens laravel erstellen. Die Gruppe besteht aus allen Benutzern, die Zugriff auf die Speicher- und Bootstrap / Cache-Verzeichnisse benötigen. Als Nächstes müssen wir sicherstellen, dass neu erstellte Dateien und Ordner die Berechtigungen laravel group und 664 bzw. 775 haben.

Es ist einfach, dies für vorhandene Dateien / Verzeichnisse zu tun, aber ein wenig Magie ist erforderlich, um die Standardregeln zum Erstellen von Dateien / Ordnern zu optimieren ...

## 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

Rein für Debugging-Zwecke fand ich, dass es vorteilhaft war, die Protokolle in beide cli / web + -Nutzer aufzuteilen, sodass ich Sam Wilsons Antwort leicht modifizierte. Mein Anwendungsfall war, dass die Warteschlange unter einem eigenen Benutzer ausgeführt wurde, sodass zwischen dem Composer-Benutzer, der die CLI (z. B. Komponententests) verwendet, und dem Warteschlangendämon unterschieden werden konnte.

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

Laravel 5.1

In unserem Fall wollten wir alle Protokolldateien so erstellen, dass alle Mitglieder der deployGruppe über Lese- / Schreibberechtigungen verfügen. Daher mussten wir alle neuen Dateien mit 0664Berechtigungen erstellen , im Gegensatz zur 0644Standardeinstellung.

Wir haben auch einen Formatierer hinzugefügt, um Zeilenumbrüche für eine bessere Lesbarkeit hinzuzufügen:

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

Es ist auch möglich, dies mit der akzeptierten Antwort zu kombinieren

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

Eine Möglichkeit, diese Arbeit ohne Laravel zu erledigen, besteht darin, Ihren Cronjob einfach als WWW-Daten auszuführen.

zB /ubuntu/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

Laravel 5.5

Fügen Sie diesen Code hinzu zu 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);
});

• Es werden Dateien wie diese gespeichert: laravel-2018-01-27-cli-raph.logund laravel-2018-01-27-fpm-cgi-raph.logdie besser lesbar sind.
• Neue Zeilen bleiben erhalten (standardmäßig Laravel-Verhalten)
• Es funktioniert mit Laravel Log Viewer

Laravel 5.6

Sie müssen eine Klasse für Ihren Logger erstellen :

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

Dann müssen Sie es registrieren in config/logging.php:

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

Gleiches Verhalten wie bei 5.5:

• Es werden Dateien wie diese gespeichert: laravel-2018-01-27-cli-raph.logund laravel-2018-01-27-fpm-cgi-raph.logdie besser lesbar sind.
• Neue Zeilen bleiben erhalten (standardmäßig Laravel-Verhalten)
• Es funktioniert mit Laravel Log Viewer

Fügen Sie am Anfang Ihrer app/start/artisan.phpDatei Folgendes hinzu (dies ist bei Laravel 4 der Fall):

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

Passen Sie den Pfad an, wenn die von Ihnen erwähnte tägliche Protokolldatei nicht die Standard-Laravel-Protokolldatei ist. Möglicherweise möchten Sie auch nicht die Gruppe ändern oder die Berechtigungen festlegen, wie ich es hier tue. Mit dem obigen Befehl wird die Gruppe auf www-dataund die Gruppenschreibberechtigungen festgelegt. Ich habe dann meinen regulären Benutzer zur www-dataGruppe hinzugefügt, damit das Ausführen von Handwerkerbefehlen als regulärer Benutzer weiterhin in das Protokoll schreiben kann.

Eine verwandte Optimierung besteht darin, Folgendes an den Anfang Ihrer app/start/global.phpDatei zu setzen:

umask(0002);

Wenn Sie dies tun, wird die chmodobige Zeile streitig. Wenn die Umask so eingestellt ist, werden für alle neuen Dateien, die PHP (und damit auch für Laravel) erstellt, die Berechtigungen nur maskiert, damit "andere" Benutzer keine Schreibberechtigungen haben. Dies bedeutet, dass Verzeichnisse als rwxrwxr-xund Dateien als beginnen rw-rw-r--. Wenn www-dataalso PHP ausgeführt wird, können alle erstellten Cache- und Protokolldateien standardmäßig von jedem in der Hauptgruppe des Benutzers geschrieben werden www-data.

(Laravel 5.6) Ich bin kürzlich auf dasselbe Problem gestoßen und habe einfach einen geplanten Befehl zum Ausführen festgelegt /app/Console/Kernel.php.

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

Ich weiß, dass es ein bisschen übertrieben ist, aber es funktioniert wie ein Zauber und hat seitdem keine Probleme mehr gehabt.

Laravel 5.4

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

zur bootFunktion hinzufügen inAppServiceProvider

Laravel 5.8

Mit Laravel 5.8 können Sie den Protokollnamen festlegen config/logging.php.

Wenn Sie also unter Verwendung vorheriger Antworten und Kommentare Ihr Protokoll sowohl mit dem tatsächlichen Posix-Benutzernamen als auch mit dem php_sapi_name()Wert benennen möchten , müssen Sie nur den Protokollnamensatz ändern. Die Verwendung des täglichen Treibers ermöglicht die Protokollrotation, die pro Benutzer / API-Kombination ausgeführt wird. Dadurch wird sichergestellt, dass das Protokoll immer von einem Konto gedreht wird, das die Protokolle ändern kann.

Ich habe auch eine Überprüfung für die Posix-Funktionen hinzugefügt, die in Ihrer lokalen Umgebung möglicherweise nicht vorhanden sind. In diesem Fall wird der Protokollname standardmäßig verwendet.

Angenommen, Sie verwenden den Standardprotokollkanal "täglich", können Sie den Schlüssel "Kanäle" folgendermaßen ändern:

# 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,
    ],
    ...

Dies führt zu einem Protokollnamen, der für jede Kombination eindeutig sein sollte, z. B. laravel-cli-sfscs-2019-05-15.logoder laravel-apache2handler-apache-2019-05-15.logabhängig von Ihrem Zugriffspunkt.

Sie können einfach die Berechtigung der Protokolldatei in Ihrem handwerklichen Befehl ändern:

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

Dabei gibt get_current_user () den Benutzer des aktuellen Skripts zurück.

Mit anderen Worten, daily.logwird immer www-dataals Eigentümer haben, auch wenn Sie das Skript als rootBenutzer initialisieren .

Wenn Sie Laravel Envoyer verwenden , gibt es hier eine mögliche Lösung für die Verwendung von ACL unter Linux:

1. Führen Sie zunächst das folgende Skript mit rootBerechtigungen auf dem Server aus:

In beiden Skripten müssen Sie die Variablen wie unten beschrieben ersetzen:

• {{MASTER_PATH}} : Der Pfad zu Ihrem virtuellen Hosts-Verzeichnis (z. B. der Ordner>, der Ihre Anwendung (en) enthält).
• {{WEB_SERVER_USER}} : Der Benutzer, den Ihr Webserver verwendet.
• {{DEPLOYMENT_USER}} : Der Benutzer, von dem Ihr Bereitstellungsskript ausgeführt wird.

#!/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. Richten Sie den folgenden Bereitstellungs-Hook im Envoyer unter "Neue Version aktivieren"> "Vor dieser Aktion" ein

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. Stellen Sie Ihre Anwendung erneut bereit

Stellen Sie jetzt Ihre Anwendung erneut bereit, und sie sollte in Zukunft funktionieren.

Hinweis: Das in 1. definierte Skript sollte jedes Mal ausgeführt werden, wenn Sie dem Computer ein neues Projekt hinzufügen.

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

Der beste Weg, den ich gefunden habe, ist, dass fideloper vorschlägt, http://fideloper.com/laravel-log-file-name , Sie können die Laravel-Protokollkonfiguration festlegen, ohne die Protokollklasse zu berühren. Ich denke, es ist die beste Lösung, unterschiedliche Namen für Konsolenprogramme und HTTP-Programme zu haben.

Diese Lösung funktioniert definitiv unter Laravel V5.1 - V6.x.

Gründe für diesen Fehler:

• Es gibt hauptsächlich Gründe für Berechtigungsprobleme
• Umgebungsvariablen nicht gefunden oder .envDatei nicht in Ihrem Stammverzeichnis gefunden
• Problem mit PHP-Erweiterungen
• Datenbankproblem

Fix:

• Legen Sie die richtigen Berechtigungen fest:
  • Führen Sie diese Befehle aus (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

• Wenn keine ENV- Datei vorhanden ist, erstellen Sie eine von, touch .envfügen Sie Ihre Umgebungsvariablen ein und führen Sie sie aus

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