La carpeta existe, pero no se puede escribir dentro

Esta guía es para el caso en el que Vulnity sí encuentra su carpeta segura, pero no puede escribir archivos dentro.

Cuándo usar esta guía

Úsala si en WordPress ves un aviso parecido a este:

Vulnity found the secure firewall storage directory, but it could not write files inside it...
Vulnity found its secure log storage directory, but it could not write files inside it...

Qué significa

La carpeta ya existe, pero PHP no puede guardar archivos dentro.

La ruta principal es:

wp-content/vulnity-data/

Y las subcarpetas que necesita Vulnity son:

wp-content/vulnity-data/firewall/
wp-content/vulnity-data/logs/

Qué debes hacer

Corrige permisos de escritura en estas rutas:

wp-content/vulnity-data/
wp-content/vulnity-data/firewall/
wp-content/vulnity-data/logs/

Solución rápida desde el panel de hosting

Abre el administrador de archivos de tu hosting.
Entra en la instalación de WordPress.
Ve a wp-content/.
Entra en vulnity-data/.
Cambia permisos de:
- vulnity-data
- firewall
- logs
Prueba primero con:

Si sigue fallando, prueba:

Recarga el panel de WordPress.

Si con `775` sigue fallando

Entonces el problema probablemente no es el permiso numérico, sino el propietario o grupo.

Ejemplo típico:

wp-content/ pertenece a user:user
wp-content/vulnity-data/logs/ pertenece a root:root

En ese caso, PHP puede seguir sin escribir aunque la carpeta tenga 775.

Solución por SSH

Desde la raíz de WordPress:

chmod 755 wp-content/vulnity-data
chmod 755 wp-content/vulnity-data/firewall
chmod 755 wp-content/vulnity-data/logs

Si sigue saliendo el aviso:

chmod 775 wp-content/vulnity-data
chmod 775 wp-content/vulnity-data/firewall
chmod 775 wp-content/vulnity-data/logs

Es importante que el propietario no sea root, que sea igual que el de las demás carpetas.

Comprobar propietario y grupo

stat -c '%U %G %n' wp-content wp-content/vulnity-data wp-content/vulnity-data/firewall wp-content/vulnity-data/logs

Lo recomendable es que vulnity-data, firewall y logs tengan el mismo propietario/grupo que wp-content.

Corregir propietario y grupo

Si conoces el usuario correcto:

chown -R <usuario>:<grupo> wp-content/vulnity-data

Ejemplo:

chown -R user:user wp-content/vulnity-data

Si sigue sin funcionar

Normalmente el problema ya no es el número de permisos, sino el propietario o grupo del directorio.

Puedes enviar esto a tu hosting:

Vulnity intenta repararlo automáticamente

En cada carga de página del admin — y, desde el plugin 1.4.0, en cada heartbeat (aprox. cada 6 horas) — Vulnity reintenta elevar los permisos de la carpeta (chmod 755) antes de rendirse. Si el problema de propietario subyacente se corrige, el aviso se limpia solo en la siguiente comprobación, y el badge de aviso del panel de Vulnity se limpia con el siguiente heartbeat. Los pasos manuales solo hacen falta cuando PHP realmente no tiene permisos de escritura sobre estas carpetas.

Cómo comprobar que ya está resuelto

Cuando esté bien:

Desaparecerá el aviso de Vulnity.
El plugin podrá crear o actualizar:

wp-content/vulnity-data/firewall/blocks.php
wp-content/vulnity-data/logs/vulnity-log.php

Qué no hace falta tocar

No hace falta tocar Apache.
No hace falta tocar Nginx.
No hace falta cambiar nada en uploads — salvo que el mensaje que veas mencione wp-content/uploads/vulnity-data, que es una carpeta distinta con su propia guía.
No hace falta usar 777 salvo prueba temporal muy puntual.