Italiano
Español
РусскийActualizarea WordPress eșuează cu eroarea "permission denied"?
Am o instalație WordPress care refuză să se actualizeze automat folosind butonul standard de actualizare din panoul de control. Eroarea primită este:
"Se despachetează actualizarea… Actualizarea nu poate fi instalată deoarece nu vom putea copia unele fișiere. Acest lucru se întâmplă de obicei din cauza permisiunilor inconsistente ale fișierelor: wp-admin/includes/update-core.php….. Instalarea a eșuat"
Atenție: copy(/var/www/html/wp-admin/includes/update-core.php): nu s-a putut deschide fluxul: Permisiune refuzată în /var/www/html/wp-admin/includes/class-wp-filesystem-direct.php la linia 281
Informații despre site:
- Pe Compute Engine din Google Cloud
- Cheie publică și intrări în firewall configurate corect pentru a permite accesul la baza de date, ssh2 etc. de pe desktopul local
- Site-ul rulează cu Apache, PHP 7.3, MariaDB pe un sistem Centos 7
- Toate funcțiile, cu excepția actualizării, funcționează corect. Acestea includ toate paginile, articolele etc. și actualizările plugin-urilor
- Toate permisiunile pentru fișiere sunt setate la 664, iar pentru foldere la 775, conform recomandărilor WordPress
- În fișierul wp-config există "define('FS_METHOD','direct');"
- Utilizatorul WordPress este "apache"
- Utilizatorul FTP este "ftpusername"
- ftpusername aparține grupului ftpusername, la fel ca și apache
- Toate fișierele și folderele sunt deținute de apache
- Toate fișierele și folderele aparțin grupului "apache"
Accesul la site se face prin SFTP Filezilla cu utilizatorul "ftpusername" și cheie privată. SSH folosește MobaXterm cu același utilizator și cheie privată.
Trebuie să determin ce utilizator folosește procesul de actualizare WordPress, deoarece nu este același utilizator care rulează toate celelalte pagini și articole, având în vedere că toate fișierele și folderele au proprietarul apache.
Trebuie să determin sub ce utilizator rulează procesul de actualizare WordPress, deoarece nu este același utilizator care rulează toate celelalte pagini și articole, având toate fișierele și directoarele deținute de apache.
Procesul de actualizare WordPress nu are nicio idee sub ce utilizator rulează, nici nu îi pasă. Nici măcar nu verifică utilizatorul, și de ce ar face-o. Proprietarul fișierului și utilizatorul sub care rulează procesul PHP pot diferi intenționat. Dacă este utilizatorul greșit, WordPress nu va ști și nici nu va putea face nimic în legătură cu asta.
Tot codul rulat prin PHP-FPM va rula sub același utilizator, indiferent dacă este WordPress sau un simplu info.php plasat în rădăcina site-ului.
Iată problema ta:
Warning: copy(/var/www/html/wp-admin/includes/update-core.php): failed to open stream: Permission denied in /var/www/html/wp-admin/includes/class-wp-filesystem-direct.php on line 281
Codul rulat din fișierele PHP nu are permisiunea de a modifica acel fișier. Această avertizare PHP este de la PHP însuși, nu este ceva generat de WordPress.
Trebuie să:
- confirmi că fișierul este înscrisibil/ștersibil de către utilizatorul procesului PHP
- confirmi că directorul este înscrisibil/ștersibil de către utilizatorul procesului PHP. Doar pentru că permisiunile fișierului sunt bune nu înseamnă că și cele ale directorului sunt bune
- verifici că proprietatea acelui director este corectă, atât pentru utilizatorul proprietar, cât și pentru grupul proprietar. Doar pentru că permisiunile fișierului și directorului sunt bune, nu înseamnă că se aplică și utilizatorului procesului PHP.
Nu este la fel de simplu ca setarea numărului corect de permisiuni cu chmod. Proprietatea contează enorm.
De exemplu, 664:
664 este inutil pentru tine dacă proprietarul este root. apache nu este nici utilizatorul root, nici în grupul root (presupun că este cazul pe sistemul tău specific).
Ca rezultat, apache ar cădea în categoria other, iar alte grupuri au doar drepturi de citire.
Totuși, dacă ar fi deținut de un alt utilizator care ar face parte din același grup ca apache, sau dacă ar fi deținut de apache însuși, atunci 664 ar putea funcționa, deoarece s-ar aplica drepturile de proprietar sau de grup.
Dar 775?
Este la fel, dar ai făcut fișierele executabile.
Deci nu există o soluție specifică WordPress pentru problema ta, care este că directoarele nu sunt înscrisibile de scripturile PHP.
Ca o observație laterală, ar trebui să faci toate fișierele de bază WordPress doar citite pentru utilizatorul PHP, astfel încât malware-ul să nu le poată modifica, apoi să folosești un instrument extern pentru actualizarea WordPress, cum ar fi WP CLI pe un cron job, sau controlul versiunilor precum git.
În orice caz, problema și soluția ta implică proprietatea și permisiunile fișierelor/directoarelor. Poate utilizatorul tău apache nu se află în grupul potrivit. Poate nu deține fișierele? Doar tu poți spune.
Mulțumesc... Pentru testare, am făcut toate fișierele și folderele 777 pe site. M-am asigurat că toți utilizatorii pe Apache, PHP erau într-un grup comun. Apropo, acesta este un site de test. Aceeași eroare a apărut. Mi-ar plăcea să știu fișierul sau folderul pe care WP încearcă să îl creeze, dar nu pot să-l determin. WP nu oferă alte informații de eroare în afară de mesajul pe care l-am documentat deja.
Rick9004
Îți spune în mesajul de eroare, /var/www/html/wp-admin/includes/update-core.php. 777 este o permisiune periculoasă de setat, deoarece înseamnă că oricine poate scrie în acel fișier, indiferent de cine sunt, și oricine îl poate executa. De exemplu, fișiere JPEG încărcate ar putea fi executate. De asemenea, nu WP afișează eroarea, ci PHP. Ai primi aceeași eroare dacă Drupal sau Joomla ar încerca să scrie în acel fișier. Cum am spus în răspunsul meu, nu este vorba despre ghicirea celor 3 numere corecte de utilizat. Problema probabil este legată de proprietate și grupuri, și nu ai oferit nicio informație despre în ce grup sunt fișierele și utilizatorul.
Tom J Nowell