¿Actualización abortada, "descarga fallida" o "unauthorized" en producción? El proceso de actualización no tiene permiso o propiedad sobre los archivos que WordPress necesita modificar, lo que provoca fallos, pérdida de tiempo y riesgo de seguridad. Con diagnósticos y pasos accionables se recupera la capacidad de actualizar sin probar a ciegas en producción.
Permisos de archivos que bloquean actualizaciones: Si las actualizaciones de WordPress fallan por permisos, ajusta propietario y permisos seguros (directorios 755, archivos 644) y cambia el propietario al usuario del servidor (ej. www-data) con comandos específicos según hosting; luego comprueba actualizaciones y backups. Se ofrecen comandos listos para cPanel, Plesk y SSH, scripts de diagnóstico y pasos de rollback que preservan la seguridad.
Permisos de archivos que bloquean actualizaciones
La razón inmediata es que el proceso que escribe no tiene permiso o propiedad sobre los archivos que WordPress necesita modificar. Un archivo o carpeta sin permiso de escritura provoca errores como "Descarga fallida" o "Unauthorized" en el panel. Estos fallos se detectan en logs y con pruebas de escritura desde el usuario del servidor web.
Cómo ocurre el bloqueo
Un propietario equivocado impide que PHP o el proceso web escriba en el árbol de WordPress. Los errores típicos son chown aplicados a root o al usuario FTP equivocado, y chmod 777 como parche temporal que causa más problemas. El error más frecuente en este punto es cambiar todo a root por comodidad y luego perder la capacidad de PHP para escribir.
Señales y logs que lo confirman
Los signos más claros son mensajes EACCES o Permission denied en los logs de Apache, NGINX o PHP-FPM. También aparecen errores en WP-Admin al iniciar una actualización. Use tail y journalctl para corroborarlo: los logs muestran la causa si se interpreta la línea con el UID o nombre del proceso.
Casos reales y matices que alteran la solución
En entornos distintos la misma orden no funciona: cPanel, Plesk, servidores con PHP-FPM y hostings managed requieren reglas diferentes. Esto funciona bien en teoría, pero en la práctica el owner correcto cambia según si PHP corre con mod_php, PHP-FPM o como usuario del panel. Identificar ese usuario es clave antes de aplicar chown.
Hostings managed y paneles que sobrescriben
Muchos hostings managed ignoran cambios manuales en permisos porque usan snapshots o agentes que restablecen estados. En esos casos no aplicar chown/chmod; abra un ticket y aporte el snapshot de permisos y los logs. Un caso habitual: aplicar cambios por SSH y ver que se revierten a las horas por el sistema de control del proveedor.
SELinux, NFS y atributos inmutables
SELinux o AppArmor pueden bloquear escrituras aunque POSIX parezca correcto. Los sistemas remotos (NFS/CIFS) a menudo traducen UID/GID y muestran permisos distintos. Los atributos inmutables (chattr +i) impiden modificaciones incluso al propietario. Comprobar estos elementos evita acciones inútiles.
Diagnóstico y comandos de auditoría
Hacer un diagnóstico completo antes de tocar permisos evita romper el sitio. Cree snapshots de permisos y ACLs, detecte el usuario del proceso web y pruebe una escritura controlada desde ese usuario. Los comandos siguientes funcionan en la raíz del sitio.
Snapshot rápido de permisos y ACLs
Guarde un listado POSIX y las ACLs antes de cambiar nada. Esto permite rollback exacto.
cd /ruta/a/wordpress
find . -type f -printf '%P|%M|%u|%g/n' > /root/wp-perms-files-$(date +%F).txt
find . -type d -printf '%P|%M|%u|%g/n' > /root/wp-perms-dirs-$(date +%F).txt
getfacl -R . > /root/wp-acl-$(date +%F).acl
lsattr -R . | grep -E 'i' > /root/wp-immutable-$(date +%F).txt || true
El snapshot tarda según el tamaño del directorio; en sitios medianos suele durar entre 1 y 10 minutos. El error típico aquí es no comprobar espacio en disco y cortar el proceso a mitad.
Script de comprobación del usuario
Detecte el usuario que ejecuta PHP o el servidor web y pruebe escritura con sudo. Incluye variantes comunes.
ps aux | egrep '(apache|httpd|nginx|php-fpm)' | awk '{print $1}' | sort -u
sudo -n -u www-data bash -c 'php -r "file_put_contents(/"wp-content/uploads/perm-test-/$(date +%s).txt/",/"ok/"); echo /"WRITE_OK/";"' && echo "web write OK" || echo "web write FAIL"
Si la prueba devuelve WRITE_FAIL, la causa es permisos, owner, ACL o contexto SELinux. El comando sudo puede no existir en algunos paneles; en ese caso pruebe con la cuenta SSH del usuario propietario.
1
Guardar snapshot POSIX y ACL (find/getfacl)
2
Detectar usuario del proceso web (ps / pool.d)
3
Probar escritura como ese usuario (sudo -u)
4
Aplicar cambios seguros y verificar logs
Script diagnóstico automático
Un diagnóstico reproducible ayuda a identificar si las actualizaciones están bloqueadas por permisos o por el entorno. El script ideal combina: comprobación de propietario (stat o find -printf '%u:%g'), listado de ACLs (getfacl -R), atributos inmutables (lsattr -R | grep -E 'i'), contexto SELinux (sestatus y ls -Z), espacio en disco (df -h), y una prueba de escritura con el usuario web (sudo -n -u <webuser> php -r 'file_put_contents("wp-content/uploads/perm-test.txt","ok");'). Únelas en un único script que devuelve un resumen tipo "OWNER_OK / ACLS_ISSUE / SELINUX_ENFORCING / DISK_OK / WRITE_FAIL" y deja los ficheros de snapshot (wp-perms-YYYYMMDD.txt, wp-acl-YYYYMMDD.acl, wp-immutable-YYYYMMDD.txt) listos para adjuntar al ticket o para rollback. Incluir este script en la guía permite ejecutar un diagnóstico en staging o producción (con permisos de lectura) y priorizar la acción correcta: chown/chmod, restaurar contexto SELinux con restorecon, o pedir al proveedor que ajuste NFS UID/GID.
Reparación segura por tipo de hosting
Ajustar propietario y permisos depende del entorno: en cPanel y Plesk el owner suele ser el usuario del panel; en servidores con PHP-FPM el owner suele ser el usuario del pool. Identificar el caso evita errores críticos. Lo que omiten la mayoría de guías es que el owner correcto no es siempre www-data.
cPanel y Plesk
En cPanel use la cuenta del suscriptor como owner. Comandos rápidos:
- cd /home/usuario/public_html find . -type d -exec chmod 755 {} /
- find . -type f -exec chmod 644 {} /
- chmod 600 wp-config.php chown -R usuario:usuario
En Plesk el flujo es similar pero la ruta típica es /var/www/vhosts/sitio/httpdocs y el usuario es el suscriptor. El error típico es usar www-data en cPanel y romper permisos del panel.
SSH con Apache/NGINX y PHP-FPM
Determine el usuario del pool y aplique chown a ese usuario. Comandos:
grep -R "user =" /etc/php//fpm/pool.d/.conf || ps aux | grep php-fpm
- cd /var/www/mi-site find . -type d -exec chmod 755 {} /
- find . -type f -exec chmod 644 {} /
- chmod 600 wp-config.php chown -R www-data:www-data
Si el servidor usa mod_php, el usuario puede ser el mismo que el proceso Apache. El peligro habitual es cambiar owner a root por tener acceso root en SSH.
Snapshot, rollback y medidas de seguridad
Siempre crear un backup o snapshot de permisos antes de aplicar chown/chmod recursivos. Un snapshot permite revertir exactamente permisos y propietarios, lo que evita horas de trabajo si algo falla. En servidores grandes el snapshot y la copia completa pueden tardar entre 10 y 60 minutos.
Crear snapshot con stat y getfacl
Comandos para crear el snapshot legible por script de rollback:
cd /ruta/a/wordpress
find . -exec stat -c '%a %U %G %n' {} /; > /root/wp-perms-snapshot-$(date +%F).txt
getfacl -R . > /root/wp-acl-snapshot-$(date +%F).acl
Este formato facilita un rollback línea por línea. El fallo frecuente es no comprobar que el archivo snapshot no tenga líneas truncadas por caracteres especiales en nombres.
Script de rollback básico
Plantilla para revertir usando el snapshot anterior. Adaptar según formato exacto.
while IFS= read -r line; do
perm=$(echo "$line" | awk '{print $1}')
owner=$(echo "$line" | awk '{print $2}')
group=$(echo "$line" | awk '{print $3}')
path=$(echo "$line" | cut -d' ' -f4-)
chmod "$perm" "$path" || true
chown "$owner:$group" "$path" || true
done < /root/wp-perms-snapshot-YYYY-MM-DD.txt
setfacl --restore=/root/wp-acl-snapshot-YYYY-MM-DD.acl || true
Comprobar el script primero en staging y probarlo en pocos ficheros antes de aplicarlo al conjunto. No ejecutar sin haber guardado el snapshot.
Pruebas post-arreglo y checklist operativo
Después de aplicar cambios, ejecutar pruebas concretas: comprobación de escritura, WP-CLI como usuario web y revisión de logs en busca de EACCES. Es la forma segura de confirmar que las actualizaciones ya funcionan. Una verificación completa tarda entre 5 y 30 minutos según el sitio.
Pruebas con WP-CLI y escritura
Comandos de verificación:
sudo -u www-data wp core check-update
sudo -u www-data wp plugin list
sudo -u www-data bash -c 'php -r "file_put_contents(/"wp-content/uploads/perm-test-/$(date +%s).txt/",/"ok/");"' && echo OK || echo FAIL
Si WP-CLI falla con permisos, el owner o ACL sigue incorrecto. Pruebe también un plugin pequeño no crítico en staging para confirmar que la actualización completa funciona.
Revisar logs y comprobar ausencia
Revise las últimas líneas de los logs y busque Permission denied o EACCES. Comandos:
tail -n 200 /var/log/apache2/error.log | grep -iE 'permission|EACCES' || true
journalctl -u php-fpm -n 200 | grep -iE 'permission|EACCES' || true
Si los errores desaparecen y la prueba de escritura pasa, la reparación fue efectiva. Un fallo frecuente es olvidar comprobar SELinux y ver solo permisos POSIX.
| Escenario |
Acción recomendada |
Riesgo |
Tiempo estimado |
| Servidor con SSH |
chown a usuario PHP-FPM + chmod estándar |
Medio |
10-30 min |
| cPanel/Plesk |
Usar usuario del panel o File Manager |
Bajo |
5-15 min |
| Managed sin SSH |
Abrir ticket con snapshot y logs |
Bajo |
1-48 h |
No aplique estas instrucciones en hostings managed sin acceso al sistema de archivos; en esos casos el proveedor puede revertir cambios. Tampoco sirven si el fallo se debe a falta de espacio en disco, credenciales FTP/SFTP incorrectas o conflictos de plugins/temas. Verifique primero logs y espacio disponible antes de cambiar permisos.
Si se necesita soporte para aplicar estos comandos y garantizar rollback seguro, se puede solicitar un diagnóstico técnico que incluya snapshot, corrección y verificación de actualizaciones.
Instrucciones prácticas para hostings
En entornos managed o donde solo tienes SFTP/File Manager, no basta con pedir que apliquen cambios: hay pasos concretos que facilitan la intervención del soporte. Genera y adjunta un snapshot legible desde el panel o SFTP (por ejemplo, desde File Manager crea un ZIP del árbol y descarga un listado con permisos) y captura los errores desde WP‑Admin y los Apache logs. Si sólo tienes SFTP, descarga el árbol comprimido o usa el listado remoto (ls -l desde clientes que lo soporten) y añade un ejemplo de fallo (mensaje ‘Descarga fallida’ o contenido de wp‑debug.log). En el ticket incluye: 1) archivo con find . -printf '%P|%M|%u|%g' o equivalente desde File Manager, 2) hora exacta del intento de actualización y últimas líneas de Apache/Nginx/PHP‑FPM, 3) una prueba de escritura realizada por el proveedor o una captura de touch wp-content/uploads/perm-test.txt y su resultado. Adjuntar snapshot y prueba acelera que el equipo managed aplique chown/chmod correctos o ajuste SELinux sin que tengas que acceder por SSH.
Diferencia entre propiedad y permisos
Es clave distinguir owner (UID/GID) de permisos POSIX: la propiedad determina qué usuario y grupo poseen el inode; chmod define qué bits (lectura/escritura/ejecución) aplican a owner, group y others. En servidores con PHP‑FPM conviene asignar owner al usuario del pool (por ejemplo www-data o phppooluser) con chown -R www-data:www-data . cuando PHP corre como www-data; en cPanel/Plesk suele ser mejor chown -R usuario:usuario porque el proceso escribe como el usuario del panel. Si se necesita compartir escritura entre PHP y una cuenta de despliegue, use grupos y ACLs (setfacl -R -m g:deploy:rwx wp-content) en vez de dar 777. Tenga en cuenta NFS: los UID/GID numéricos deben coincidir entre servidor y cliente; si no, verá propietarios extraños aunque ls -l muestre permisos aparentemente correctos. Para wp‑config.php prefiera 600 o 640 y, si usa 640, asegúrese de que el grupo incluye al proceso web. Finalmente, atributos como chattr +i bloquean escritura incluso al owner; compruébelo con lsattr antes de cambiar permisos o propiedad.
Preguntas frecuentes
¿Por qué mi WordPress muestra "Descarga fallida"
Respuesta: Porque el proceso que escribe no tiene permiso o propiedad sobre el archivo que WordPress intenta modificar. Revise logs y haga la prueba de escritura desde el usuario del servidor web para confirmar.
¿Qué permisos usar en carpetas y archivos?
Respuesta: Use 755 en directorios y 644 en archivos como regla general. Wp-config.php debe quedar en 600 o 640 según el server. Evite 777 salvo pruebas en entornos aislados.
¿Debo cambiar owner a www-data siempre?
Respuesta: No. En cPanel/Plesk el owner suele ser el usuario del panel. En servidores propios, asigne owner al usuario del pool PHP-FPM o al usuario del servidor web. Identifique el usuario antes de chown.
¿Cómo revierto cambios si algo falla?
Respuesta: Use el snapshot creado con stat/getfacl y ejecute un script de rollback que restituya permisos y propietarios línea por línea. No borre el snapshot antes de verificar en staging.
¿SELinux puede impedir actualizaciones aunque los permisos POSIX sean correctos?
Respuesta: Sí. SELinux en modo enforcing bloquea escrituras según contexto. Use restorecon o chcon para corregir contexto y luego pruebe la actualización.
¿Qué hago si el hosting gestiona los permisos
Respuesta: Adjunte el snapshot y los logs al ticket del proveedor y solicite que apliquen los cambios. No intente forzar chown en paneles donde el proveedor gestiona el sistema.
¿Puedo usar WP-CLI para actualizar tras arreglar
Respuesta: Sí. Ejecutar WP-CLI como el usuario web (sudo -u usuario wp ...) confirma que las actualizaciones funcionan desde el proceso que debe escribir.
Tu próximo paso
Realice estas tres acciones en orden:
- Cree el snapshot de permisos y ACLs
- Detecte y pruebe escritura con el usuario del proceso web
- Aplique permisos y owner seguros en staging y verifique con WP-CLI. Si SELinux, NFS o paneles gestionados están presentes, incluya la comprobación correspondiente antes del cambio
Los datos aportan contexto: según W3Techs 2023 WordPress impulsa alrededor del 43% de las webs. OWASP Top Ten identifica controles de acceso incorrectos como riesgo importante para aplicaciones web. Planear y guardar snapshots reduce el tiempo de reparación a minutos en muchos casos.
Para más soporte técnico especializado, el servicio ofrece diagnóstico y aplicación de los pasos descritos con rollback y pruebas; pida revisión si prefiere que el equipo ejecute estos comandos y verifique las actualizaciones finalizadas.
