Si al intentar actualizar un plugin, subir una imagen o instalar un tema desde el escritorio de WordPress te aparece el mensaje «No ha sido posible conectar con el sistema de archivos. Por favor, confirma tus credenciales», no es un fallo de tu internet ni de tu sitio. Es un problema de permisos o de propietario entre WordPress y el servidor donde está alojado. Esta guía te lleva paso a paso por las tres causas más comunes y cómo resolverlas desde cPanel, sin perder el contenido del sitio.
El mensaje sale siempre que WordPress necesita escribir un archivo en el servidor (subir una imagen, guardar una actualización, instalar un plugin) y el sistema operativo se lo impide. En hosting compartido con cPanel, las dos causas más habituales son que el usuario del sistema que ejecuta PHP no es el mismo que el propietario de los archivos, o que los permisos son demasiado restrictivos. Vamos a ver las tres.
Puntos clave
- El error «No ha sido posible conectar con el sistema de archivos» es un problema de permisos o de propietario entre WordPress y el servidor, no de tus credenciales FTP.
- En la mayoría de casos se resuelve pidiendo a cPanel que iguale el propietario de los archivos con el usuario que ejecuta PHP, o ajustando los permisos a 755 para carpetas y 644 para archivos.
- WordPress puede pedirte credenciales FTP por dos razones: porque detecta que no puede escribir directamente, o porque el módulo FTP del servidor no está habilitado.
- El hosting compartido de cPanel incluye una herramienta de «Restablecer permisos» que deja todo en valores correctos con un solo clic.
- Si todo lo anterior falla, queda la opción de declarar las credenciales SSH en el archivo wp-config.php, pero es el último recurso y solo si sabes lo que haces.
Por qué aparece el error
WordPress se ejecuta como un usuario del sistema operativo. Cuando necesita escribir un archivo (subir una foto, instalar un plugin, guardar una actualización), lo intenta hacer con los permisos que tiene. Si el archivo o la carpeta donde quiere escribir pertenece a otro usuario, el sistema operativo se lo impide y WordPress responde con el mensaje genérico «No ha sido posible conectar con el sistema de archivos».
En hosting compartido, el usuario que ejecuta PHP no siempre coincide con el propietario de los archivos que se subieron por FTP o por el instalador automático de Softaculous. Esto es así por seguridad, pero al mismo tiempo impide que WordPress escriba sin más. De ahí viene el error.
Solución 1 — Restablecer los permisos desde cPanel
Es la solución más rápida y la que funciona en la mayoría de casos:
- Entra en cPanel.
- Abre la herramienta «Administrador de archivos» o «File Manager».
- Navega hasta la carpeta donde está instalado WordPress (normalmente
public_html). - Selecciona todas las carpetas y archivos (Ctrl+A o Cmd+A).
- Haz clic derecho y elige «Permisos» o «Change Permissions».
- Para carpetas: pon 755. Para archivos: pon 644. Marca «Aplicar a subcarpetas» y «Aplicar a archivos».
- Confirma. La operación puede tardar un minuto si tienes muchos archivos.
Estos son los permisos estándar de cualquier instalación WordPress en hosting compartido y coinciden con lo que WordPress espera. Después de aplicarlos, vuelve a tu escritorio y prueba a instalar el plugin o subir la imagen que antes fallaba.
Si tu hosting es como el nuestro y te permite acceso SSH, esto puedes hacerlo también por consola.
Solución 2 — Igualar el propietario de los archivos
Si los permisos son correctos pero el error sigue, lo más probable es que el usuario que ejecuta PHP no sea el propietario de los archivos. Esto pasa sobre todo cuando se sube WordPress por FTP y luego Softaculous intenta actualizarlo, o cuando se restaura un sitio desde una copia de seguridad que tenía otro propietario.
Para corregirlo:
- Desde cPanel, abre la herramienta «Conexión SSH» o «Terminal» si tu plan la incluye.
- Si no tienes Terminal, abre el «Administrador de archivos», ve a la carpeta de WordPress, y en la barra superior busca «Cambiar propietario» o «Reset Owner».
- Cambia el propietario de toda la estructura de WordPress al usuario de tu cuenta de cPanel (es el mismo que aparece como «Propietario» en la columna izquierda del Administrador de Archivos).
- Para aplicar el cambio a subcarpetas y archivos, marca la casilla recursiva.
- Espera a que termine. Puede tardar varios minutos si tienes una web grande con muchos archivos multimedia.
Tras este cambio, WordPress y el sistema que ejecuta PHP pasan a ser el mismo usuario, y la escritura directa vuelve a funcionar.
Solución 3 — Definir las credenciales en wp-config.php
WordPress tiene un sistema alternativo que consiste en dar las credenciales del servidor directamente en wp-config.php. Es la opción que usa cuando el escritorio te pide usuario y contraseña FTP. Esta solución es válida, pero tiene un inconveniente: deja una contraseña escrita en un archivo PHP, lo cual es un riesgo de seguridad si no se trata con cuidado.
Si decides usarla, añade estas líneas al final de wp-config.php (antes del comentario «That’s all, stop editing»):
define('FS_METHOD', 'direct');
define('FTP_HOST', 'ftp.tudominio.example');
define('FTP_USER', 'tu_usuario_cpanel');
define('FTP_PASS', 'tu_contraseña_ftp');
La primera línea le dice a WordPress que intente escribir directamente sin pedir credenciales. Si la primera funciona, no necesitas las otras tres. Si la primera falla, WordPress usará las credenciales FTP.
Tras guardar el archivo, prueba de nuevo desde el escritorio de WordPress.
Errores típicos que conviene evitar
- Establecer permisos 777 para «arreglar» el problema. Los 777 son inseguros y en hosting compartido están normalmente desactivados por seguridad. Los permisos correctos son 755 para carpetas y 644 para archivos.
- Tocar el archivo
.htaccesspara añadir directivas de suPHP o mod_php. En hosting compartido moderno (con LiteSpeed o PHP-FPM) esto no es necesario y puede romper la configuración del servidor. - Editar wp-config.php desde el escritorio de WordPress en lugar de desde el Administrador de Archivos de cPanel. El editor de WordPress no maneja bien los finales de línea en algunos sistemas y puede introducir caracteres invisibles.
- Cambiar el propietario a «nobody» o «apache». Estos son usuarios del sistema operativo, no son cuentas que puedas usar. El propietario correcto es siempre tu usuario de cPanel.
Cómo encaja esto en el hosting compartido
El error «No ha sido posible conectar con el sistema de archivos» es uno de los mensajes más comunes de WordPress en hosting compartido, precisamente porque la separación entre el usuario que ejecuta PHP y el propietario de los archivos es deliberada. Es una capa de seguridad que te protege frente a inyecciones de código, pero que requiere un paso manual cuando subes o restauras contenido por una vía distinta a la habitual.
Los planes de hosting compartido de cPanel incluyen la herramienta «Restablecer permisos» en su panel, así que con un par de clics puedes dejar la instalación en un estado conocido sin tener que abrir un ticket de soporte. Si prefieres que lo hagamos por ti, el Companion Hosting incluye tareas de mantenimiento del sistema de archivos como parte del plan, así que podemos revisar permisos, propietario y configuración PHP sin que tengas que entrar en cPanel.
Conclusión
El error «No ha sido posible conectar con el sistema de archivos» casi siempre tiene solución sin reinstalar nada. Restablece permisos desde cPanel (755 para carpetas, 644 para archivos), iguala el propietario de los archivos a tu usuario de cPanel si hace falta, y solo si nada de eso funciona añade las credenciales FTP en wp-config.php. Tu contenido queda intacto en todos los pasos.
Si prefieres un hosting que se ocupe de esto en segundo plano, los planes de hosting que ofrecemos en Liberty Dreams incluyen permisos correctos por defecto, asistencia para restablecer el propietario cuando algo se desajusta y un equipo de soporte que puede tomar el relevo si el problema aparece en un sitio en producción.
Preguntas frecuentes
¿Por qué WordPress me pide credenciales FTP si nunca las he usado?
WordPress pide credenciales FTP cuando detecta que no puede escribir directamente en el sistema de archivos. Esto pasa en hosting compartido cuando el usuario que ejecuta PHP no es el propietario de los archivos. Si nunca has usado FTP en tu sitio, es una pista de que el problema es de permisos o de propietario, no de credenciales reales.
¿Es seguro escribir la contraseña FTP en wp-config.php?
Es una opción válida pero tiene riesgo. La contraseña queda en un archivo PHP plano, y si alguien consigue leer wp-config.php (por ejemplo, por una vulnerabilidad en otro plugin), ve esa contraseña. Por eso solo se recomienda como último recurso, después de probar las soluciones 1 y 2. Si la usas, mantén wp-config.php con permisos 600 o 640 para que solo tu usuario y el servidor puedan leerlo.
¿Cambiar el propietario puede romper algo?
Cambiar el propietario al usuario correcto de cPanel es la solución que recomienda WordPress para este problema y no rompe nada siempre que el destino sea tu usuario de cPanel, no un usuario del sistema como «apache» o «nobody». Si tienes un cron que se ejecuta como otro usuario, revisa que ese cron siga funcionando tras el cambio. En el 99% de los casos no hay cron que dependa de otro usuario.
¿Cada cuánto hay que revisar los permisos?
En condiciones normales, los permisos no se desajustan solos. Se desajustan cuando algo externo toca los archivos: una migración, una restauración desde una copia de seguridad, un script que sube contenido masivamente, o un plugin que escribe fuera de su carpeta. Si tu sitio lleva meses funcionando sin tocar nada, probablemente no necesitas revisarlos. Si has hecho cualquiera de las operaciones anteriores, vale la pena comprobarlos.
¿Tiene algo que ver con el módulo LiteSpeed?
No directamente. LiteSpeed es el servidor web que sirve las páginas, no es quien decide los permisos de los archivos. Los permisos los decide el sistema operativo en función del propietario y del grupo. Que el servidor web sea LiteSpeed o Apache no cambia el problema ni la solución. Lo que sí puede pasar es que el servidor web ejecute PHP con un usuario concreto (en algunos casos «nobody»), y ese es el dato relevante para diagnosticar.


