L'aggiornamento di WordPress fallisce con un errore "permesso negato"?
Ho un'installazione di WordPress che si rifiuta di aggiornarsi automaticamente utilizzando il pulsante standard di aggiornamento nella dashboard. L'errore ricevuto è:
"Scompattamento dell'aggiornamento... L'aggiornamento non può essere installato perché non siamo in grado di copiare alcuni file. Questo è solitamente dovuto a permessi dei file inconsistenti.: wp-admin/includes/update-core.php..... Installazione Fallita"
Avviso: 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
Informazioni sul sito:
- Su Google Cloud Compute Engine
- Chiave pubblica e regole firewall appropriate per consentire l'accesso al DB, ssh2, ecc. dal desktop locale
- Il sito gira con Apache, PHP 7.3, MariaDB su un sistema CentOS 7
- Tutte le funzioni eccetto l'aggiornamento funzionano bene. Questo include tutte le pagine normali, articoli, ecc. e gli aggiornamenti dei plugin
- Tutti i permessi dei file sono impostati a 664, le cartelle a 775 come raccomandato da WordPress
- Nel file wp-config c'è "define('FS_METHOD','direct');"
- L'utente WordPress è "apache"
- L'utente FTP è "ftpusername"
- ftpusername appartiene al gruppo ftpusername come apache
- Tutti i file e le cartelle sono di proprietà di apache
- Tutti i file e le cartelle appartengono al gruppo "apache"
L'accesso al sito avviene via SFTP Filezilla con utente "ftpusername" e chiave privata. SSH utilizza MobaXterm con lo stesso utente e chiave privata
Devo determinare quale utente il processo di aggiornamento di WordPress pensa di essere, dato che non è l'utente che esegue tutte le altre pagine e articoli poiché ho tutti i file e le cartelle di proprietà di apache.

Devo determinare quale utente il processo di aggiornamento di WordPress pensa di essere, poiché non è lo stesso utente che gestisce tutte le altre pagine e articoli, dato che ho tutti i file e le cartelle di proprietà di apache.
Il processo di aggiornamento di WordPress non ha idea né si preoccupa di quale utente stia eseguendo. Non verifica nemmeno l'utente, e perché dovrebbe farlo? Il proprietario del file e l'utente sotto cui è in esecuzione il processo PHP potrebbero differire deliberatamente. Se si tratta dell'utente sbagliato, WordPress non lo saprà né potrà fare nulla al riguardo.
Tutto il codice eseguito da PHP-FPM verrà eseguito sotto lo stesso utente, indipendentemente dal fatto che si tratti di WordPress o di un rapido info.php
posizionato nella radice web.
Ecco il tuo problema:
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
Il codice eseguito dai file PHP non ha il permesso di modificare quel file. Questo avviso PHP proviene da PHP stesso, non è qualcosa che WordPress ha generato.
Devi:
- verificare che il file sia scrivibile/cancellabile dall'utente del processo PHP
- verificare che la cartella sia scrivibile/cancellabile dall'utente del processo PHP. Solo perché il permesso del file è corretto non significa che lo sia anche quello della cartella
- che la proprietà di quella cartella sia corretta, sia per l'utente proprietario che per il gruppo proprietario. Solo perché i permessi del file e della cartella sono corretti, non significa che si applichino all'utente del processo PHP.
Non è così semplice come impostare il numero di permesso corretto con chmod. La proprietà è estremamente importante.
Ad esempio, 664:
664 è inutile se il proprietario è root
. apache
non è né l'utente root
né nel gruppo root
(supponendo che sia così sul tuo sistema specifico).
Di conseguenza, apache
rientrerebbe nel bucket other
, e gli altri gruppi hanno solo accesso in lettura.
Tuttavia, se fosse di proprietà di un altro utente che condivide lo stesso gruppo di apache
, o se fosse di proprietà di apache
stesso, allora 664
potrebbe funzionare poiché si applicherebbero i diritti del proprietario o del gruppo.
E 775?
È lo stesso ma hai reso i file eseguibili.
Quindi non esiste una soluzione specifica di WordPress per il tuo problema, che è che le cartelle non sono scrivibili dagli script PHP.
Come nota a margine, dovresti rendere tutti i file core di WordPress di sola lettura per l'utente PHP in modo che il malware non possa modificarli, quindi utilizzare uno strumento esterno per aggiornare WordPress, come WP CLI su un cron job, o un sistema di controllo versione come git
.
In ogni caso, il tuo problema e la sua soluzione riguardano la proprietà e i permessi di file/cartelle. Forse il tuo utente apache non è nel gruppo appropriato. Forse non possiede i file? Solo tu puoi dirlo.

Grazie... Per il testing ho impostato tutti i file e le cartelle a 777 nel sito. Mi sono assicurato che tutti gli utenti su Apache, PHP fossero in un gruppo comune. BTW questo è un sito di test. Lo stesso errore si è verificato. Mi piacerebbe sapere il file o la cartella che WP sta cercando di creare, ma non riesco a determinarlo. WP non fornisce altre informazioni sull'errore oltre al messaggio che ho già documentato.

Te lo dice nel messaggio di errore, /var/www/html/wp-admin/includes/update-core.php
. 777
è un permesso pericoloso da impostare perché significa che chiunque può scrivere su quel file, indipendentemente da chi sia, e chiunque può eseguirlo. Ad esempio, i file JPEG caricati potrebbero essere eseguiti. Inoltre, non è WP che mostra l'errore, è PHP. Otterresti lo stesso errore se Drupal o Joomla provassero a scrivere su quel file. Come ho detto nella mia risposta, non si tratta di indovinare i 3 numeri corretti da usare. La proprietà e i gruppi sono probabilmente il problema, e non hai fornito alcuna informazione su quale gruppo appartengano i file e l'utente.
