Italiano
Română
РусскийError "permiso denegado" al actualizar WordPress
Tengo una instalación de WordPress que se niega a actualizarse automáticamente usando el botón estándar de actualización en el panel. El error recibido es:
"Desempaquetando la actualización... La actualización no se puede instalar porque no podremos copiar algunos archivos. Esto generalmente se debe a permisos de archivos inconsistentes: wp-admin/includes/update-core.php..... Instalación fallida"
Advertencia: copy(/var/www/html/wp-admin/includes/update-core.php): no se pudo abrir el flujo: Permiso denegado en /var/www/html/wp-admin/includes/class-wp-filesystem-direct.php en la línea 281
Información sobre el sitio:
- En Compute Engine de Google Cloud
- Clave pública y entradas de firewall apropiadas para permitir acceso a DB, ssh2, etc. desde el escritorio local
- El sitio funciona con Apache, PHP 7.3, MariaDB en un sistema Centos 7
- Todas las funciones excepto la actualización funcionan bien. Esto incluye todas las páginas normales, publicaciones, etc. y las actualizaciones de plugins
- Todos los permisos de archivos están configurados a 664, carpetas a 775 como recomienda WordPress
- En el archivo wp-config hay "define('FS_METHOD','direct');"
- El usuario de WordPress es "apache"
- El usuario FTP es "ftpusername"
- ftpusername pertenece al grupo ftpusername al igual que apache
- Todos los archivos y carpetas son propiedad de apache
- Todos los archivos y carpetas pertenecen al grupo "apache"
El acceso al sitio es mediante SFTP Filezilla con usuario "ftpusername" y clave privada. SSH usa MobaXterm con el mismo usuario y clave privada.
Necesito determinar qué usuario cree el proceso de actualización de WordPress que es, ya que no es el usuario que ejecuta todas las demás páginas y publicaciones, ya que tengo todos los archivos y carpetas propiedad de apache.
Necesito determinar qué usuario cree el proceso de actualización de WordPress que es, ya que no es el usuario que ejecuta todas las demás páginas y publicaciones, ya que tengo todos los archivos y carpetas propiedad de apache.
El proceso de actualización de WordPress no tiene idea de bajo qué usuario se está ejecutando, ni le importa. Ni siquiera verifica el usuario, y por qué debería hacerlo. El propietario del archivo y el usuario bajo el cual se ejecuta el proceso PHP pueden diferir deliberadamente. Si es el usuario incorrecto, WordPress no lo sabrá ni podrá hacer nada al respecto.
Todo el código ejecutado por PHP-FPM se ejecutará bajo el mismo usuario, independientemente de si es WordPress o un info.php rápido que coloques en la raíz web.
Aquí está tu 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
El código ejecutado desde archivos PHP no tiene permiso para modificar ese archivo. Esa advertencia de PHP proviene del propio PHP, no es algo que WordPress haya generado.
Necesitas:
- confirmar que el archivo es escribible/borrable por el usuario del proceso PHP
- confirmar que la carpeta es escribible/borrable por el usuario del proceso PHP. Que los permisos del archivo sean correctos no significa que los de la carpeta también lo sean
- que la propiedad de esa carpeta sea correcta, tanto para el usuario propietario como para el grupo propietario. Permisos correctos en archivo y carpeta no garantizan que apliquen al usuario del proceso PHP.
No es tan simple como establecer el número de permiso correcto con chmod. La propiedad importa enormemente.
Por ejemplo, 664:
664 es inútil si el propietario es root. apache no es ni el usuario root ni está en el grupo root (asumo que ese es el caso en tu sistema específico).
Como resultado, apache caería en el grupo otros, y los otros grupos solo tienen acceso de lectura.
Sin embargo, si fuera propiedad de otro usuario que compartiera el mismo grupo que apache, o si fuera propiedad de apache mismo, entonces 664 podría funcionar ya que aplicarían los derechos de propietario o grupo.
¿Qué hay de 775?
Es lo mismo pero has hecho que los archivos sean ejecutables.
Así que no hay una solución específica de WordPress para tu problema, que es que las carpetas no son escribibles por scripts PHP.
Como nota aparte, deberías hacer que todos los archivos principales de WordPress sean de solo lectura para el usuario PHP para que el malware no pueda modificarlos, y luego usar una herramienta externa para actualizar WordPress, como WP CLI en un trabajo cron, o control de versiones como git.
De cualquier manera, tu problema y solución involucran propiedad y permisos de archivos/carpetas. Quizás tu usuario apache no está en el grupo apropiado. ¿Tal vez no es propietario de los archivos? Solo tú puedes determinarlo.
Gracias... Para probar, establecí todos los archivos y carpetas con permisos 777 en el sitio. Me aseguré de que todos los usuarios en Apache, PHP estuvieran en un grupo común. Por cierto, este es un sitio de prueba. Ocurrió el mismo error. Me encantaría saber qué archivo o carpeta está intentando crear WP, pero no puedo determinarlo. WP no muestra más información de error aparte del mensaje que ya he documentado.
Rick9004
El mensaje de error te lo indica, /var/www/html/wp-admin/includes/update-core.php. 777 es un permiso peligroso de establecer ya que significa que cualquiera puede escribir en ese archivo, sin importar quién sea, y cualquiera puede ejecutarlo. Por ejemplo, archivos JPEG subidos podrían ser ejecutados. Además, no es WP el que muestra el error, es PHP. Obtendrías el mismo error si Drupal o Joomla intentaran escribir en ese archivo. Como dije en mi respuesta, esto no se trata de adivinar los 3 números correctos a usar. La propiedad y los grupos probablemente son el problema, y no has proporcionado información sobre en qué grupo están los archivos y el usuario.
Tom J Nowell