WordPress necessita que el procés PHP o d’actualització escrigui en directoris concrets del nucli, connectors, temes i temporals. «Permission denied» indica un conflicte de propietari o mode, no que tot el web hagi de ser escrivible per tothom.
Conserva la ruta exacta i l’usuari del procés abans de canviar permisos de manera recursiva.
Registra l’operació fallida
Anota el component, la versió del paquet, l’hora i la ruta completa protegida. Consulta els registres PHP i del servidor.
Identifica:
fitxer o directori
propietari i grup
mode numèric o simbòlic
controlador i usuari PHP
mètode del sistema de fitxers
estat del disc i els inodesOculta noms de compte als informes compartits.
Confirma l’usuari PHP actiu
cPanel o Plesk poden executar PHP com a usuari del compte, usuari del pool o usuari web compartit. Les ordres CLI poden utilitzar-ne un altre i crear fitxers que WordPress no pugui substituir.
Utilitza eines de l’allotjament o proves del procés. No dedueixis l’usuari només pels fitxers propers.
Alinea desplegaments, cron i WP-CLI amb l’usuari previst.
Revisa els directoris superiors
Escriure un fitxer exigeix permisos adequats a cada directori pare. Comprova la ruta i els seus antecessors, inclòs wp-content/upgrade, el directori del component i el temporal.
La destinació pot semblar escrivible i fallar perquè un directori pare no té permís d’execució o recorregut.
No canviïs les pujades o la configuració si l’error esmenta només un directori de paquet.
Utilitza la reparació de propietat de l’allotjament
En allotjament compartit, cPanel, Plesk o el proveïdor han de reparar els propietaris creats per restauracions o migracions. En un VPS, ho ha de fer algú que entengui el controlador PHP i el desplegament.
Directoris 755 i fitxers 644 són habituals, no universals. La propietat acostuma a ser més important.
No apliquis 777 recursiu; permet escriptures no autoritzades i no resol SELinux ni ACL.
Comprova ACL i polítiques de seguretat
Les llistes ACL, els atributs immutables, SELinux o AppArmor i els muntatges de només lectura poden denegar l’escriptura encara que els bits normals semblin correctes.
Utilitza registres d’auditoria i eines autoritzades. No desactivis tota la política per permetre actualitzacions.
Crea només l’etiqueta o regla necessària i prova una operació.
Retira temporals antics amb seguretat
Una actualització interrompuda pot deixar wp-content/upgrade o la destinació amb un altre propietari. Fes còpia i confirma que no hi ha cap procés.
Elimina només el paquet temporal concret amb el mateix compte fiable. No esborris el connector actiu sense conservar-ne els fitxers i la reversió.
Comprova disc i inodes abans de repetir.
Revisa les credencials de fitxers
Quan WordPress no pot escriure directament, pot demanar FTP o FTPS. Confirma que el proveïdor admet aquest mètode i que el compte es limita a l’arrel correcta.
No desis contrasenyes FTP a wp-config.php tret que el disseny i la política ho exigeixin. Prefereix SFTP o desplegament segur; FTP transmet credencials. Una sol·licitud repetida pot indicar propietat incorrecta, no una contrasenya errònia.
Decideix si WordPress ha d’escriure codi
Alguns desplegaments gestionats o versionats fan immutable el codi de producció. Les actualitzacions han de passar a staging o a la canalització, no des de l’escriptori.
No afebleixis una infraestructura immutable. Actualitza el repositori i desplega per la via autoritzada.
Mantén les pujades i les memòries cau escrivibles per separat segons calgui.
Verifica l’herència dels directoris
Els fitxers nous poden heretar grup, ACL o umask diferents. Crea i elimina un fitxer inofensiu amb el mateix usuari i revisa el propietari i el mode.
Corregeix els valors predeterminats perquè la propera actualització continuï funcionant; un chmod puntual tornarà a fallar. Coordina amb el proveïdor si el panell restableix propietaris.
Verifica seguretat i actualització
Reintenta una actualització fiable i confirma la substitució completa, l’absència de versions barrejades i el buidatge d’OPcache. Prova el web i l’administració.
Revisa després permisos massa amplis, especialment a wp-config.php i al codi. El manteniment recurrent ha de comprovar propietaris després de migracions i documentar una única via aprovada per actualitzar sense convertir la reparació en una regressió de seguretat.