Diagnosticos
- Error de Permisos en Subida de Archivos en WordPress Dentro de un Contenedor Docker
- La contraseña admin/admin por defecto en Filebrowser no funciona.
Error de Permisos en Subida de Archivos en WordPress Dentro de un Contenedor Docker
Si el contenedor Docker de WordPress esta mapeado a un volumen personalizado, es posible que el problema esté relacionado con los permisos en la carpeta mapeada en su sistema host, es decir, en /home/${USER}/volumendocker/wordpress/
.
Muchas recomendaciones en linea indicar que los permisos deberia ser configurados a 755, pero a mi solo me funciono despues de configurarlos a 777.
Pasos para Resolver:
Verifique los Permisos en el Sistema Host:
- Asegúrese de que el usuario bajo el cual se ejecuta el contenedor Docker tiene los permisos necesarios para escribir en la carpeta mapeada. Puede hacerlo cambiando los permisos con el siguiente comando en su host:
bash chmod -R 777 /home/${USER}/volumendocker/wordpress/wp-content/uploads
- Si es necesario, también asegúrese de que el propietario del directorio es el usuario correcto. Por ejemplo, si Docker se ejecuta bajo un usuario específico, puede cambiar la propiedad con:
bash chown -R <docker_user>:<docker_user> /home/${USER}/volumendocker/wordpress/wp-content/uploads
Verifique la Configuración de Volúmenes en Docker:
- Asegúrese de que el volumen está correctamente montado y que los cambios en el sistema host se reflejan dentro del contenedor. Puede verificarlo entrando en el contenedor y revisando los permisos en la carpeta
/var/www/html/wp-content/uploads
:bash docker exec -it <nombre_del_contenedor> /bin/bash
ls -l /var/www/html/wp-content/uploads
- Esto le permitirá ver si los permisos y la propiedad en el contenedor son correctos. En caso contrario, ejecute el comando aqui usando el camino por defecto del contenedor.
chmod -R 755 /var/www/html/wp-content/uploads
Reinicie el Contenedor:
- Si ha realizado cambios en los permisos o la configuración, puede ser útil reiniciar el contenedor Docker para asegurarse de que los cambios se aplican correctamente:
bash docker restart <nombre_del_contenedor>
Si después de realizar estos pasos sigue teniendo problemas, puede ser útil revisar los logs del contenedor Docker para ver si hay algún otro error adicional que pueda estar afectando las subidas.
La contraseña admin/admin por defecto en Filebrowser no funciona.
En la imagen oficial de filebrowser/filebrowser, el único usuario incorporado es admin, pero la contraseña se genera aleatoriamente la primera vez que se inicia el contenedor y solo se muestra una vez en los registros del contenedor. Si vuelve a crear el contenedor sin mantener la base de datos SQLite, FileBrowser entra nuevamente en “modo primera ejecución”, genera una nueva contraseña y no podrá iniciar sesión con la anterior. Para evitar esto, monte la base de datos (y opcionalmente el settings.json) en una ruta persistente en el host o en un volumen nombrado. Si prefiere usar una contraseña fija, puede establecer FB_USER y FB_PASSWORD (o usar el CLI) la primera vez.
1. ¿Cuál es el usuario y contraseña por defecto?
Imagen / versión |
Usuario |
Contraseña en el primer inicio |
---|---|---|
Imagen oficial Alpine / S6 (v2.x) |
admin |
Cadena aleatoria mostrada una sola vez en logs |
Algunas guías antiguas o no oficiales |
admin |
admin |
¿Dónde encontrar la contraseña aleatoria?
docker logs <nombre_del_contenedor> | grep -i "generated password"
Si ya no aparece, puede restablecer la contraseña desde dentro del contenedor:
docker exec -it <nombre_del_contenedor> filebrowser users update admin --password NUEVAPASS
2. ¿Por qué se reinicia la contraseña cada vez que actualizo?
-
FileBrowser guarda los usuarios y configuraciones en un solo archivo SQLite (/database/filebrowser.db o /database.db, según la imagen).
-
Si actualiza la imagen o recrea el contenedor y no ha montado ese archivo en un volumen persistente, Docker crea una capa nueva de archivos vacía. FileBrowser no encuentra la base de datos y vuelve a generarla desde cero con nueva contraseña aleatoria.
3. ¿Cómo mantener el acceso después de actualizar?
Ejemplo docker-compose.yml:
version: "3.9"
services:
filebrowser:
image: filebrowser/filebrowser:latest # o especifique una versión fija
container_name: filebrowser
ports:
- "8080:80"
environment:
- PUID=1000
- PGID=1000
# Opcional: defina credenciales fijas al crear por primera vez la DB
- FB_USER=admin
- FB_PASSWORD=SuperSecreta123
volumes:
- /srv/files:/srv
- /opt/filebrowser/filebrowser.db:/database/filebrowser.db
- /opt/filebrowser/settings.json:/config/settings.json # Opcional
restart: unless-stopped
-
Montar /database/... y /config/... asegura que los usuarios, contraseñas y la configuración de interfaz se mantengan incluso al actualizar el contenedor.
-
Fijar el tag de imagen (v2.36.3, por ejemplo) evita cambios inesperados.
-
Si usa herramientas como Watchtower, use etiquetas para controlar cuándo actualizar.
4. Cambiar o restablecer la contraseña del admin
Método |
Comando |
---|---|
Desde el host |
docker exec -it filebrowser filebrowser users update admin --password NUEVAPASS |
Con variables de entorno (una vez) |
-e FB_USER=admin -e FB_PASSWORD=NUEVAPASS |
Desde la interfaz web |
Usuarios → Editar |
5. Consejos adicionales
-
Haga una copia de seguridad de filebrowser.db; es pequeña y contiene todo.
-
Asegúrese de que los permisos en el host sean correctos (chown 1000:1000) para que el contenedor pueda escribir en el archivo.
-
Use variables PUID y PGID para que el contenedor se ejecute como su usuario del host (mejor seguridad).
-
Puede poner FileBrowser detrás de Traefik (que usted ya usa), para añadir HTTPS y protección adicional con middlewares.
Resumen
El usuario siempre es admin; la contraseña es aleatoria (imagen oficial) o admin (guías antiguas). El motivo por el que “pierde” el acceso es porque la base de datos desaparece cuando el contenedor se reinicia sin una capa persistente. Monte ese archivo o defina sus propias credenciales una vez, y no volverá a tener este problema.