Jak ustawić uprawnienia plików dla Laravel?
Używam serwera Apache, który ma właściciela ustawionego na _www:_www
. Nigdy nie wiem, jaka jest najlepsza praktyka z uprawnieniami do plików, na przykład podczas tworzenia nowego projektu Laravel 5.
Laravel 5 wymaga folderu /storage
do zapisu. Znalazłem wiele różnych podejść, aby to działało i zwykle kończę na tym, że robię to rekurencyjnie 777
chmod. Wiem, że to nie jest najlepszy pomysł.
Oficjalny lekarz mówi:
Laravel może wymagać uprawnienia do konfiguracji: foldery wewnątrz
storage
ivendor
wymagają dostępu do zapisu przez serwer WWW.
Czy to znaczy, że serwer WWW potrzebuje dostępu do samych folderów storage
i vendor
czy tylko ich bieżącej zawartości?
Zakładam, że to, co jest dużo lepsze, to zmiana właściciela zamiast uprawnień. Zmieniłem rekurencyjnie uprawnienia wszystkich plików Laravela na _www:_www
i to sprawiło, że strona działała poprawnie, tak jakbym zmienił chmod na 777
. Problem czy teraz mój edytor tekstu prosi mnie o hasło za każdym razem, gdy chcę zapisać dowolny plik i to samo dzieje się, jeśli próbuję coś zmienić w Finderze, na przykład skopiuj plik.
Jakie jest właściwe podejście do rozwiązania tych problemów?
- Zmień
chmod
- Zmień właściciela plików, aby pasował do tych z
serwer WWW i może ustawić edytor tekstu (i Finder?) aby pominąć
Prośba o hasło lub ich użycie
sudo
- Zmień właściciela strony serwer do dopasowania do użytkownika os (nie poznaj konsekwencje)
- Something else
17 answers
Tylko dla stwierdzenia oczywistości dla każdego, kto ogląda tę dyskusję.... jeśli nadasz któremuś z folderów 777 uprawnienia, zezwalasz każdemu na odczyt, zapis i wykonanie dowolnego pliku w tym katalogu.... oznacza to, że dałeś każdemu (hakerowi lub złośliwej osobie na całym świecie) pozwolenie na przesłanie dowolnego pliku, wirusa lub innego pliku, a następnie wykonanie tego pliku...
JEŚLI USTAWIASZ UPRAWNIENIA FOLDERU NA 777, OTWORZYŁEŚ SWÓJ SERWER DLA KAŻDEGO, KTO MOŻE ZNAJDŹ TEN KATALOG. Jasne??? :)
Istnieją zasadniczo dwa sposoby skonfigurowania własności i uprawnień. Albo dajesz sobie prawo własności, albo sprawiasz, że serwer internetowy jest właścicielem wszystkich plików.
Webserver jako właściciel (tak jak większość ludzi to robi, a sposób Laravel doc):
Zakładając, że www-data (może to być coś innego) jest użytkownikiem twojego serwera www.
sudo chown -R www-data:www-data /path/to/your/laravel/root/directory
Jeśli to zrobisz, serwer jest właścicielem wszystkich plików, a także jest grupą, a Ty będziesz masz problemy z przesyłaniem plików lub pracą z plikami przez FTP, ponieważ twój klient FTP będzie zalogowany jako ty, a nie twój serwer WWW, więc Dodaj użytkownika do grupy użytkowników serwera www: {]}
sudo usermod -a -G www-data ubuntu
Oczywiście, zakłada to, że twój serwer działa jako www-data (domyślnie Homestead), a Twoim użytkownikiem jest ubuntu (jest to vagrant, jeśli używasz Homestead).
Następnie ustawiasz wszystkie katalogi na 755, a pliki na 644... SET file permissions
sudo find /path/to/your/laravel/root/directory -type f -exec chmod 644 {} \;
Ustaw katalog uprawnienia
sudo find /path/to/your/laravel/root/directory -type d -exec chmod 755 {} \;
Twój użytkownik jako właściciel
Wolę posiadać wszystkie katalogi i pliki (ułatwia to pracę ze wszystkim), więc przejdź do głównego katalogu laravel:
cd /var/www/html/laravel >> assuming this is your current root directory
sudo chown -R $USER:www-data .
Następnie daję zarówno sobie, jak i serwerowi uprawnienia:
sudo find . -type f -exec chmod 664 {} \; sudo find . -type d -exec chmod 775 {} \;
Następnie nadaj serwerowi prawa do odczytu i zapisu do storage and cache
Niezależnie od tego, w jaki sposób go skonfigurujesz, musisz nadać serwerowi www uprawnienia do odczytu i zapisu w celu przechowywania, cache i wszelkie inne katalogi, które serwer WWW musi przesłać lub zapisać (w zależności od sytuacji), więc uruchom polecenia z bashy powyżej:
sudo chgrp -R www-data storage bootstrap/cache sudo chmod -R ug+rwx storage bootstrap/cache
Teraz jesteś bezpieczny i Twoja strona działa, i możesz pracować z plikami dość łatwo
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2020-12-12 13:40:04
Uprawnienia folderów storage
i vendor
powinny pozostać w 775
, z oczywistych względów bezpieczeństwa.
Jednak zarówno Twój komputer, jak i twój serwer Apache muszą być w stanie pisać w tych folderach. Ex: kiedy uruchamiasz polecenia takie jak php artisan
, Twój komputer musi zapisywać w pliku logów w storage
.
Wszystko, co musisz zrobić, to dać własność folderów Apache :
sudo chown -R www-data:www-data /path/to/your/project/vendor
sudo chown -R www-data:www-data /path/to/your/project/storage
Następnie należy dodać swój komputer (o którym mowa username
) do grupy, do której serwer Apache należy. Tak:
sudo usermod -a -G www-data userName
Uwaga: najczęściej groupName
jest www-data
, ale w Twoim przypadku zastąp go _www
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-07-19 19:15:17
Podczas konfigurowania uprawnień dla aplikacji Laravel napotkaliśmy wiele przypadków brzegowych. Tworzymy osobne konto użytkownika (deploy
) do posiadania folderu aplikacji Laravel i wykonywania poleceń Laravel z CLI, a następnie uruchamiamy serwer WWW pod www-data
. Jedną z przyczyn jest to, że pliki dziennika mogą być własnością www-data
lub deploy
, w zależności od tego, kto napisał do pliku dziennika jako pierwszy, co oczywiście uniemożliwia innemu użytkownikowi zapisanie go w przyszłości.
Odkryłem, że jedynym zdrowym i bezpiecznym rozwiązaniem jest użycie Linux ACLs. Celem tego rozwiązania jest:
- aby umożliwić użytkownikowi, który posiada / wdraża aplikację dostęp do odczytu i zapisu kodu aplikacji Laravel (używamy użytkownika o nazwie
deploy
). - aby umożliwić użytkownikowi
www-data
dostęp do odczytu kodu aplikacji Laravel, ale nie do zapisu. - aby uniemożliwić innym użytkownikom dostęp do kodu/danych aplikacji Laravel.
- aby umożliwić zarówno użytkownikowi
www-data
, jak i użytkownikowi aplikacji (deploy
) zapisanie dostęp do folderu pamięci, niezależnie od tego, który użytkownik jest właścicielem pliku (tak więc zarównodeploy
, jak iwww-data
mogą zapisywać na przykład do tego samego pliku dziennika).
Osiągamy to w następujący sposób:
- wszystkie pliki w folderze
application/
są tworzone z domyślną maską umask0022
, co powoduje, że foldery mają uprawnieniadrwxr-xr-x
, A pliki mają uprawnienia-rw-r--r--
. -
sudo chown -R deploy:deploy application/
(lub po prostu wdrożyć aplikację jako użytkownikdeploy
, co robimy). -
chgrp www-data application/
aby daćwww-data
Grupowy dostęp do aplikacji. -
chmod 750 application/
aby zezwolić użytkownikowideploy
Na Odczyt/Zapis, użytkownikowiwww-data
Tylko do odczytu oraz aby usunąć wszystkie uprawnienia innym użytkownikom. -
setfacl -Rdm u:www-data:rwx,u:deploy:rwx application/storage/
aby ustawić domyślne prawa dostępu do folderustorage/
i wszystkich podfolderów. Wszystkie nowe foldery / pliki utworzone w folderze storage odziedziczą te uprawnienia ({[23] } zarówno dlawww-data
, jak ideploy
). -
setfacl -Rm u:www-data:rwX,u:deploy:rwX application/storage/
aby ustawić powyższe uprawnienia dla wszystkich istniejących plików / folderów.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-12-21 17:11:55
Zmień uprawnienia folderu projektu, aby włączyć Odczyt/Zapis / exec dla każdego użytkownika w grupie posiadającej Katalog (co w Twoim przypadku jest _www
):
chmod -R 775 /path/to/your/project
Następnie dodaj swoją nazwę użytkownika OS X do grupy _www
, aby umożliwić mu dostęp do katalogu:
sudo dseditgroup -o edit -a yourusername -t user _www
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-06-04 09:18:27
To mi pomogło:
cd [..LARAVEL PROJECT ROOT]
sudo find . -type f -exec chmod 644 {} \;
sudo find . -type d -exec chmod 755 {} \;
sudo chmod -R 777 ./storage
sudo chmod -R 777 ./bootstrap/cache/
Tylko jeśli używasz npm (VUE, kompilowanie SASS, itp..) add this:
sudo chmod -R 777 ./node_modules/
Co robi:
- zmień wszystkie uprawnienia do pliku na 644
- zmień wszystkie uprawnienia folderu na 755
- dla pamięci podręcznej i bootstrap (specjalne foldery używane przez laravel do tworzenia i wykonywania plików, niedostępne z zewnątrz) Ustaw uprawnienia na 777, dla czegokolwiek wewnątrz
- dla pliku wykonywalnego nodeJS, takiego samego jak wyżej
Uwaga: Może możesz nie, lub nie trzeba, aby to zrobić z prefiksem sudo. to zależy od uprawnień użytkownika, grupy, itp...
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2020-11-05 14:40:39
Większość folderów powinna być normalna " 755 " i pliki "644"
Laravel wymaga, aby niektóre foldery były zapisywalne dla użytkownika serwera www. Możesz użyć tego polecenia w systemie oss opartym na Uniksie.
sudo chgrp -R www-data storage bootstrap/cache
sudo chmod -R ug+rwx storage bootstrap/cache
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-06-06 11:40:10
Dodaj do composer.json
"scripts": {
"post-install-cmd": [
"chgrp -R www-data storage bootstrap/cache",
"chmod -R ug+rwx storage bootstrap/cache"
]
}
Po composer install
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2019-03-05 11:09:30
As posted already
Wszystko, co musisz zrobić, to dać własność folderów Apache :
Ale dodałem -R dla chown polecenie:
sudo chown -R www-data:www-data /path/to/your/project/vendor
sudo chown -R www-data:www-data /path/to/your/project/storage
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-06-01 15:49:01
The Laravel 5.4 docs say:
Po zainstalowaniu Laravel może być konieczne skonfigurowanie niektórych uprawnień. Katalogi w katalogach
storage
ibootstrap/cache
powinien być zapisywalny przez serwer WWW lub Laravel nie będzie działać. Jeśli korzystają z maszyny Wirtualnej Homestead, uprawnienia te powinny już gotowe.
Na tej stronie jest wiele odpowiedzi, które wspominają o używaniu 777
uprawnień. Nie rób tego. byłabyś ujawnienie się hakerom.
Zamiast tego postępuj zgodnie z sugestiami innych, jak ustawić uprawnienia 755 (lub bardziej restrykcyjne). Być może będziesz musiał dowiedzieć się, który użytkownik jest uruchomiony przez Twoją aplikację, uruchamiając whoami
w terminalu, a następnie zmienić własność niektórych katalogów za pomocą chown -R
.
Jeśli nie masz uprawnień do używania sudo
, tak jak wymaga tego wiele innych odpowiedzi...
Twój serwer jest prawdopodobnie współdzielonym hostem, takim jak Cloudways.
(W moim przypadek, sklonowałem moją aplikację Laravel do drugiego mojego serwera Cloudways i nie działało całkowicie, ponieważ uprawnienia katalogów storage
i bootstrap/cache
były popsute.)
Potrzebowałem użyć:
Cloudways Platform > Server > Application Settings > Reset Permission
Wtedy mógłbym uruchomić php artisan cache:clear
w terminalu.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-26 21:35:32
Rozwiązanie opublikowane przez bgles jest dla mnie na miejscu pod względem poprawnego ustawienia uprawnień na początku( używam drugiej metody), ale nadal ma potencjalne problemy z Laravel.
Domyślnie Apache tworzy pliki z uprawnieniami 644. Więc to prawie wszystko w magazynie/. Tak więc, jeśli usuniesz zawartość storage / framework/views, a następnie uzyskasz dostęp do strony za pośrednictwem Apache, zobaczysz, że widok w pamięci podręcznej został utworzony w następujący sposób:
-rw-r--r-- 1 www-data www-data 1005 Dec 6 09:40 969370d7664df9c5206b90cd7c2c79c2
Jeśli uruchomisz "artisan serve" i dostęp do innej strony, otrzymasz różne uprawnienia, ponieważ CLI PHP zachowuje się inaczej niż Apache:
-rw-rw-r-- 1 user www-data 16191 Dec 6 09:48 2a1683fac0674d6f8b0b54cbc8579f8e
Sama w sobie nie jest to nic wielkiego, ponieważ nie będziesz robił tego w produkcji. Ale jeśli Apache utworzy plik, który następnie musi być napisany przez użytkownika, to się nie powiedzie. I to Może stosować się do plików pamięci podręcznej, buforowanych widoków i dzienników podczas wdrażania przy użyciu zalogowanego użytkownika i rzemieślnika. Łatwym przykładem jest "artisan cache: clear", który nie usunie wszelkie pliki pamięci podręcznej, które są www-data:www-data 644.
Można to częściowo złagodzić, uruchamiając polecenia artisan jako www-data, więc będziesz robić / skryptować wszystko, jak:
sudo -u www-data php artisan cache:clear
Albo unikniesz żmudności tego i dodasz to do swojego .bash_aliases:
alias art='sudo -u www-data php artisan'
Jest to wystarczająco dobre i w żaden sposób nie wpływa na bezpieczeństwo. Ale na maszynach programistycznych uruchamianie skryptów testowych i sanitarnych sprawia, że jest to nieporęczne, chyba że chcesz skonfigurować aliasy do używania ' sudo-u www-data ' aby uruchomić phpunit i wszystko inne można sprawdzić swoje buildy, które mogą spowodować pliki do tworzenia.
W związku z tym, że nie jest to możliwe, nie jest to konieczne, ponieważ nie jest to konieczne, ponieważ nie jest to konieczne.]}
umask 002
Spowoduje to, że Apache domyślnie utworzy pliki jako 664. Samo w sobie może to stanowić zagrożenie dla bezpieczeństwa. Jednak w środowiskach Laravel głównie omawianych tutaj (Homestead, Vagrant, Ubuntu) serwer WWW działa jako użytkownik www-data w grupie www-data. Więc jeśli nie arbitralnie pozwalają użytkownikom dołączyć do grupy www-data, nie powinno być żadnego dodatkowego ryzyka. Jeśli komuś uda się wyrwać z serwera, to i tak ma dostęp do danych www, więc nic nie jest stracone (choć nie jest to najlepsze podejście do bezpieczeństwa). Tak więc na produkcji jest stosunkowo bezpieczny, a na maszynie programistycznej dla jednego użytkownika nie jest to po prostu problem.
Ostatecznie jako użytkownik znajduje się w grupie www-data, a wszystkie katalogi zawierające te pliki to g + s (plik jest zawsze tworzony pod grupą katalogu nadrzędnego), wszystko utworzone przez użytkownika lub przez www-data będzie r/W dla drugiego.
I to jest cel tutaj.
edytuj
Po zbadaniu powyższego podejścia do ustawiania uprawnień, nadal wygląda to wystarczająco dobrze, ale kilka poprawek może pomóc:
Domyślnie, katalogi to 775, A Pliki to 664, a wszystkie pliki mają właściciela i grupy użytkowników, którzy właśnie zainstalowali framework. Więc załóżmy, że zaczniemy od tego punktu.
cd /var/www/projectroot
sudo chmod 750 ./
sudo chgrp www-data ./
Pierwszą rzeczą, którą robimy, to zablokowanie dostępu do wszystkich innych i uczynienie grupy www-data. Tylko właściciel i członkowie www-data mogą uzyskać dostęp do katalogu.
sudo chmod 2775 bootstrap/cache
sudo chgrp -R www-data bootstrap/cache
Aby umożliwić serwerowi tworzenie usług.JSON i skompilowany.php, zgodnie z sugestią oficjalnego przewodnika instalacji Laravela. Ustawienie grupy sticky bit oznacza, że będą one własnością twórcy z grupą www-data.
find storage -type d -exec sudo chmod 2775 {} \;
find storage -type f -exec sudo chmod 664 {} \;
sudo chgrp -R www-data storage
Robimy to samo z folderem storage, aby umożliwić tworzenie plików pamięci podręcznej, dziennika, sesji i widoku. Używamy find, aby jawnie ustawić uprawnienia do katalogów w inny sposób dla katalogów i plików. Nie musieliśmy tego robić w bootstrap/cache, ponieważ nie ma tam (normalnie) żadnych podkatalogów.
Może być konieczne ponowne użycie FLAG wykonywalnych, usunięcie vendor/ * i ponowne zainstalowanie zależności composera, aby odtworzyć linki do phpunit i innych, eg:
chmod +x .git/hooks/*
rm vendor/*
composer install -o
To jest to. Z wyjątkiem umask dla Apache wyjaśnione powyżej, jest to wszystko, co jest wymagane bez tworzenia całego projektu zapisywalny przez www-data, co dzieje się z innymi rozwiązaniami. Jest to więc nieco bezpieczniejsze, ponieważ Intruz działający jako www-data ma bardziej ograniczony dostęp do zapisu.
koniec edycji
zmiany dla Systemd
Dotyczy to użycia php-fpm, ale może inne też.
Standardowa Usługa systemd musi zostać nadpisana, umask ustawiony w nadpisaniu.plik conf, a usługa uruchomiona ponownie:
sudo systemctl edit php7.0-fpm.service
Use:
[Service]
UMask=0002
Then:
sudo systemctl daemon-reload
sudo systemctl restart php7.0-fpm.service
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-11-15 04:02:18
Postanowiłem napisać własny scenariusz, aby złagodzić ból związany z tworzeniem projektów.
Uruchom następujące elementy wewnątrz katalogu głównego projektu:
wget -qO- https://raw.githubusercontent.com/defaye/bootstrap-laravel/master/bootstrap.sh | sh
Poczekaj na zakończenie bootstrapowania i możesz zaczynać.
Przejrzyj skrypt przed użyciem.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-03-10 22:43:27
Zainstalowałem laravel na instancji EC2 i spędziłem 3 dni, aby naprawić błąd uprawnień i w końcu go naprawić. Chcę więc podzielić się tym doświadczeniem z innymi.
Problem użytkownika Kiedy zalogowałem się w instancji ec2, moja nazwa użytkownika to EC2-user, a grupa użytkowników to ec2-user. A strona działa pod adresem httpd user: apache: apache więc powinniśmy ustawić pozwolenie na apache.
-
Uprawnienia do folderu i Pliku A. Struktura folderów po pierwsze, należy upewnić się, że mieć taką strukturę folderów jak ta pod storage
Przechowywanie
- framework
- cache
- sesje
- views
- logi Struktura folderów może się różnić w zależności od używanej wersji laravel. moja wersja laravel to 5.2 i możesz znaleźć odpowiednią strukturę zgodnie z twoją wersją.
- framework
B. pozwolenie Na początku widzę instrukcje, aby ustawić 777 pod magazynem, aby usunąć file_put_contents: failed aby otworzyć błąd strumienia. Więc ustawiłem pozwolenie 777 na przechowywanie chmod-R 777 storage Ale błąd nie został naprawiony. tutaj należy wziąć pod uwagę jeden: kto pisze pliki do storage / sessions i views. To nie jest ec2-user, ale apache. Tak, racja. użytkownik "apache" zapisuje plik (plik sesji, skompilowany plik widoku) do folderu session I view. Powinieneś więc dać apache ' owi uprawnienia do zapisu do tych folderów. Domyślnie: SELinux mówi, że folder / var / www powinien być tylko do odczytu przez apache deamon.
Więc w tym celu możemy ustawić selinux jako 0: setenforce 0
To może rozwiązać problem tymczasowo, ale to sprawia, że mysql nie działa. więc to nie jest tak dobre rozwiązanie.
Możesz ustawić kontekst odczytu i zapisu do folderu pamięci za pomocą: (pamiętaj, aby ustawić setenforce 1, aby go przetestować)
chcon -Rt httpd_sys_content_rw_t storage/
Wtedy twój problem zostanie rozwiązany.
-
I nie zapomnij o tym composer update PHP artisan cache: clear
Polecenia te będą przydatne po lub wcześniej.
Mam nadzieję, że zaoszczędzisz swój czas. Powodzenia. Hacken
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-07-15 10:47:32
Miałem następującą konfigurację:
- NGINX (running user:
nginx
) - PHP-FPM
I poprawnie zastosował uprawnienia Zgodnie z sugestią @bgies w zaakceptowanej odpowiedzi. Problem w moim przypadku był skonfigurowany przez PHP-fpm uruchomiony użytkownik i grupa, która pierwotnie była apache
.
nano /etc/php-fpm.d/www.config
NGINX został skonfigurowany tak, aby działać z; w moim przypadku oba były nginx
:
...
; Unix user/group of processes
; Note: The user is mandatory. If the group is not set, the default user's group
; will be used.
; RPM: apache Choosed to be able to access some dir as httpd
user = nginx
; RPM: Keep a group allowed to write in log dir.
group = nginx
...
Zapisz go i uruchom ponownie usługi nginx i php-fpm.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-11-08 12:34:57
Dla programistów Laravel problemy z katalogami mogą być trochę uciążliwe. W mojej aplikacji tworzyłem katalogi w locie i z powodzeniem przenosiłem pliki do tego katalogu w moim środowisku lokalnym. Następnie na serwerze otrzymywałem błędy podczas przenoszenia plików do nowo utworzonego katalogu.
Oto rzeczy, które zrobiłem i uzyskałem udany wynik na końcu.
-
sudo find /path/to/your/laravel/root/directory -type f -exec chmod 664 {} \;
sudo find /path/to/your/laravel/root/directory -type d -exec chmod 775 {} \;
chcon -Rt httpd_sys_content_rw_t /path/to/my/file/upload/directory/in/laravel/project/
- podczas tworzenia nowego katalogu w locie, użyłem polecenie
mkdir($save_path, 0755, true);
Po wprowadzeniu tych zmian na serwerze produkcyjnym z powodzeniem utworzyłem nowe katalogi i przeniosłem do nich pliki.
Wreszcie, jeśli używasz File facade w Laravel możesz zrobić coś takiego:
File::makeDirectory($save_path, 0755, true);
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2020-02-04 18:30:08
Pierwsza odpowiedź brzmi:
sudo chmod -R 777/775 /path/project_folder
Teraz musisz zrozumieć uprawnienia i opcje w ubuntu.
- chmod - możesz ustawić uprawnienia.
- chown - możesz ustawić własność plików i katalogów.
- 777 - Odczyt/Zapis/wykonanie.
- 775 - read/execute.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2020-12-03 07:37:48
Zrobiłbym to tak:
sudo chown -R $USER:www-data laravel-project/
find laravel-project/ -type f -exec chmod 664 {} \;
find laravel-project/ -type d -exec chmod 775 {} \;
Następnie musisz dać webserverowi pozwolenie na modyfikację katalogów storage
i bootstrap/cache
:
sudo chgrp -R www-data storage bootstrap/cache
sudo chmod -R ug+rwx storage bootstrap/cache
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2021-01-07 10:06:10
Znalazłem na to jeszcze lepsze rozwiązanie. Jest to spowodowane tym, że php domyślnie działa jako inny użytkownik.
Więc naprawić to zrobić
sudo nano /etc/php/7.0/fpm/pool.d/www.conf
Następnie Edytuj
user = "put user that owns the directories"
group = "put user that owns the directories"
Wtedy:
sudo systemctl reload php7.0-fpm
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-10-18 23:56:35