Cómo solucionar el error «Could not access filesystem» en WordPress (No se ha podido acceder al sistema de archivos)

Tabla de Contenidos

¿Por qué WordPress pide credenciales FTP? La Causa Raíz

Antes de aplicar cualquier «parche», es fundamental entender qué está ocurriendo bajo el capó. Cuando ves el error «Could not access filesystem WordPress», el sistema te está diciendo que el script PHP que ejecuta WordPress no tiene los permisos necesarios para escribir o modificar archivos en el servidor directamente.

WordPress posee un sistema de abstracción de archivos integrado. Cuando intenta escribir en la carpeta /wp-content (para subir un plugin, por ejemplo), realiza una comprobación de seguridad. Verifica si el usuario que ejecuta el servidor web (comúnmente llamado www-data en Apache/Nginx) es el mismo usuario que es propietario de los archivos de tu instalación.

• El conflicto: Si tu servidor web se ejecuta bajo un usuario (ej. apache) y tus archivos pertenecen a otro usuario (ej. tu usuario FTP personal), WordPress detecta una discrepancia de seguridad.
• La reacción: Para evitar modificar archivos que «no le pertenecen», WordPress cambia a un método seguro y te pide las credenciales FTP para realizar la operación como si fueras tú quien sube los archivos.

Solución 1: La corrección rápida con FS_METHOD (Recomendada para la mayoría)

Para el 90% de los usuarios que se encuentran en un hosting compartido o que necesitan una solución inmediata, la forma más efectiva de resolver el error «Could not access filesystem WordPress» es definiendo una constante en el archivo de configuración global.

Podemos instruir a WordPress para que evite la comprobación de seguridad estricta y utilice el sistema de archivos de manera directa. Esto se hace editando el archivo wp-config.php.

Pasos para implementar FS_METHOD: direct

1. Accede a los archivos de tu sitio web mediante un cliente FTP (como FileZilla) o a través del Administrador de Archivos de tu cPanel.
2. Localiza el archivo wp-config.php en la carpeta raíz (generalmente public_html).
3. Descarga una copia de seguridad del archivo (siempre es una buena práctica).
4. Edita el archivo y busca la línea que dice /* That's all, stop editing! Happy publishing. */.
5. Justo encima de esa línea, pega el siguiente código:

define('FS_METHOD', 'direct');

Al guardar y subir este archivo nuevamente al servidor, le estás diciendo a WordPress: «Confío en el entorno, escribe los archivos directamente sin pedir contraseñas».

Para más detalles técnicos sobre las constantes de configuración, puedes consultar la documentación oficial de WordPress sobre wp-config.php.

Solución 2: Corrección de Permisos y Propiedad (Chown y Chmod)

Si administras tu propio servidor VPS (DigitalOcean, Linode, AWS) o tienes acceso SSH, la solución anterior es un «bypass». La solución correcta y más segura es arreglar la propiedad de los archivos para que coincidan con el usuario del servidor web.

En mi flujo de trabajo desarrollando sitios de alto tráfico, prefiero asegurar que los permisos sean estrictos en lugar de forzar el método directo si el entorno lo permite. Aquí te explico cómo hacerlo.

Identificar el usuario del servidor web

Generalmente, en sistemas Linux (Ubuntu/Debian) con Apache o Nginx, el usuario es www-data. En sistemas CentOS puede ser apache.

Cambiar el propietario (Chown)

Accede a tu terminal vía SSH y navega al directorio donde está instalado WordPress. Ejecuta el siguiente comando para asignar la propiedad de todos los archivos al servidor web:

sudo chown -R www-data:www-data /var/www/html/tusitio

Asegúrate de cambiar /var/www/html/tusitio por la ruta real de tu instalación.

Corregir los permisos de lectura/escritura (Chmod)

Una vez que el propietario es correcto, debemos asegurarnos de que los directorios y archivos tengan los permisos adecuados. La regla de oro en WordPress es: 755 para carpetas y 644 para archivos.

Ejecuta estos comandos en tu terminal dentro de la carpeta raíz de tu sitio:

# Cambiar todos los directorios a 755
sudo find . -type d -exec chmod 755 {} \;

# Cambiar todos los archivos a 644
sudo find . -type f -exec chmod 644 {} \;

Solución 3: Configuración de credenciales FTP/SSH en wp-config.php

Existen escenarios donde tu proveedor de hosting tiene configuraciones de seguridad muy restrictivas que impiden el método directo (`FS_METHOD direct`) y no tienes acceso SSH para cambiar propietarios. En estos casos, para evitar que la ventana emergente aparezca cada vez, puedes «quemar» (hardcode) las credenciales en el archivo de configuración.

WordPress permite definir las constantes de conexión FTP directamente en wp-config.php. De esta forma, el CMS usará estas credenciales automáticamente en segundo plano.

Añade las siguientes líneas a tu archivo wp-config.php:

define('FTP_USER', 'tu_usuario_ftp');
define('FTP_PASS', 'tu_contraseña_ftp');
define('FTP_HOST', 'ftp.tusitio.com');
define('FTP_SSL', false); // Pon true si tu servidor soporta SSL

Uso de claves SSH (Más seguro)

Si tu servidor lo permite, es mucho más seguro utilizar claves SSH en lugar de contraseñas FTP planas. WordPress soporta esto nativamente:

define('FTP_PUBKEY', '/home/usuario/.ssh/id_rsa.pub');
define('FTP_PRIKEY', '/home/usuario/.ssh/id_rsa');
define('FTP_USER', 'usuario_ssh');
define('FTP_HOST', '127.0.0.1:22');

Soluciones específicas según el entorno

El error «Could not access filesystem WordPress» se manifiesta de manera diferente dependiendo de dónde esté alojado tu sitio. Aquí desgloso las particularidades para entornos locales vs. producción.

En Localhost (XAMPP, MAMP, Docker)

Es extremadamente común ver este error al desarrollar localmente, especialmente en macOS o Linux, debido a cómo estos sistemas manejan los permisos de usuario frente al usuario que ejecuta XAMPP o Docker.

• XAMPP/MAMP: La solución casi siempre es usar define('FS_METHOD', 'direct');. Dado que es un entorno local, los riesgos de seguridad son mínimos. No te compliques intentando configurar un servidor FTP local.
• Docker: Si usas contenedores, el problema suele ser que el volumen montado pertenece a tu usuario de sistema (UID 1000) y el contenedor espera www-data (UID 33). La solución ideal es configurar tu Dockerfile para ajustar los permisos al construir la imagen, o usar el método directo en entorno de desarrollo (DEV).

En Hosting Compartido (cPanel, Plesk)

En hostings compartidos de calidad (SiteGround, Bluehost, etc.), el servidor suele estar configurado con suPHP o FastCGI, lo que permite que los scripts PHP se ejecuten con el mismo usuario que el propietario de los archivos. Si ves este error aquí, suele ser porque:

1. Se migraron archivos manualmente y se perdieron los permisos originales.
2. El hosting tiene una configuración de seguridad muy antigua o restrictiva (DSO handler).

Si tras aplicar el FS_METHOD sigues teniendo problemas en un hosting compartido, te recomiendo contactar al soporte técnico. A veces, el proveedor necesita aplicar un chown recursivo desde su lado que tú no puedes realizar.

Preguntas Frecuentes sobre el acceso al sistema de archivos

¿Es seguro dejar FS_METHOD en ‘direct’?

Sí, en la gran mayoría de los casos modernos es seguro, siempre que el resto de tu servidor esté bien configurado. Es el estándar en la mayoría de los hostings gestionados de WordPress.

¿Por qué sucede esto después de una migración?

Cuando mueves un sitio de un servidor A a un servidor B (por ejemplo, usando un plugin de migración o moviendo archivos zip), los archivos pueden desempaquetarse con el usuario «root» o el usuario del sistema, en lugar del usuario específico de tu cuenta de hosting, generando el conflicto de «Could not access filesystem».

He probado todo y sigue fallando, ¿qué hago?

Verifica si tienes espacio en disco. A veces, un error de «no se puede escribir» se confunde con permisos, cuando en realidad el servidor está lleno (Disk Quota Exceeded).