[{"data":1,"prerenderedAt":178},["ShallowReactive",2],{"seo-verification":3,"blog-permisos-volumenes-docker-vps-es":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-permisos-volumenes-docker-vps-es",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":27,"featuredImage":29,"bgImage":30,"posterImage":31,"relatedSolution":29,"intro":32,"sections":33,"ctaTitle":135,"ctaBody":136,"ctaButton":137,"ctaUrl":138,"relatedPosts":139},395,"permisos-volumenes-docker-vps",{"fr":12,"en":13,"ar":14,"es":10},"docker-volume-permissions-self-hosted-vps","docker-volume-permissions-vps","اذونات-مجلدات-docker-vps","Permisos de volúmenes Docker: corrección en 3 comandos","¿Permission denied en tus logs de Docker? Entiende el mecanismo UID\u002FGID y corrige los permisos de volúmenes sin ejecutar nada como root.",10,0,false,"2026-09-28T00:00:00+00:00","2026-09-29T14:40:42+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},3,"Despliegue","deploiement","bg-success\u002F10 text-success",[28],{"id":23,"name":24,"slug":25,"color":26,"icon":25},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fdocker-volume-permissions-self-hosted-vps-poster.svg","La aplicación arranca, el contenedor corre, pero los logs muestran `Permission denied` y nada se guarda. Este problema afecta a prácticamente todas las aplicaciones self-hosted en el momento en que montas un directorio del host en Docker. La causa es siempre la misma: el UID del usuario que corre dentro del contenedor no coincide con el propietario del directorio en el host. Esta guía explica el mecanismo, da los comandos de diagnóstico y propone la corrección adecuada para cada caso — sin ejecutar nunca los contenedores como root.",[34,38,41,49,52,70,73,90,93,96,120,123,129,132],{"type":35,"title":36,"body":37},"h2","El mecanismo: por qué Docker se niega a escribir","Docker comparte el kernel Linux del host. Cuando un contenedor monta un directorio del host (bind-mount), el sistema de archivos aplica las mismas reglas de permisos POSIX. Un archivo propiedad del UID 1000 en el host sigue siendo propiedad del UID 1000, independientemente de si se llama `alice` en el host o `paperless` en el contenedor. Si el proceso en el contenedor corre como UID 472 y el directorio pertenece a root (UID 0), las escrituras son denegadas — aunque hayas usado `chmod 755`.\n\nTrampa clásica: creas el directorio con tu sesión SSH (UID 1000), luego lanzas un contenedor Grafana que corre como UID 472. Grafana intenta escribir su base SQLite en `\u002Fvar\u002Flib\u002Fgrafana` montado desde `\u002Fopt\u002Fgrafana\u002Fdata` — que pertenece a tu usuario SSH. Resultado: `GF_PATHS_DATA='\u002Fvar\u002Flib\u002Fgrafana' is not writable.`",{"type":35,"title":39,"body":40},"Las aplicaciones más afectadas y sus UIDs","Los problemas de permisos Docker afectan principalmente a las aplicaciones que se ejecutan con un UID específico diferente al del host.",{"type":42,"items":43},"ul",[44,45,46,47,48],"**Paperless-ngx** — UID `1000` (usuario `paperless`): gestiona los directorios `consume`, `export`, `media` y `data`","**Grafana** — UID `472` (usuario `grafana`): escribe su base SQLite y plugins en `\u002Fvar\u002Flib\u002Fgrafana`","**Nextcloud** (imagen Debian) — UID `33` (usuario `www-data`): directorio de datos, config y logs","**Immich** — UID `1000` (usuario `node`): librería de fotos, miniaturas y base de datos ML","**Gitea** — UID `1000` (usuario `git`): repositorios, claves SSH, logs y base SQLite por defecto",{"type":35,"title":50,"body":51},"Diagnóstico: identificar el problema en menos de 2 minutos","Antes de corregir, confirma que es un problema de permisos e identifica el UID implicado. Tres comandos son suficientes.",{"type":53,"steps":54},"steps",[55,58,61,64,67],{"title":56,"body":57},"Leer el mensaje de error exacto","Consulta los logs del contenedor afectado:\n```\ndocker logs \u003Cnombre-contenedor> 2>&1 | grep -i 'permission\\|denied\\|cannot\\|mkdir'\n```\nUn mensaje `permission denied` o `cannot create directory` confirma el diagnóstico.",{"title":59,"body":60},"Identificar el UID del proceso dentro del contenedor","```\ndocker exec \u003Cnombre-contenedor> id\n```\nSalida típica: `uid=472(grafana) gid=0(root)`. Apunta el UID — aquí `472`.",{"title":62,"body":63},"Verificar el propietario del directorio en el host","```\nls -ln \u002Fopt\u002Fgrafana\u002Fdata\n```\nSalida `drwxr-xr-x 2 0 0 ...` indica que el directorio pertenece a root (UID 0). El UID 472 solo tiene derechos «other» — lectura y ejecución, sin escritura.",{"title":65,"body":66},"Usar stat para un diagnóstico completo","```\nstat \u002Fopt\u002Fgrafana\u002Fdata\n```\nRevisa las líneas `Uid:` y `Gid:`. Si muestran `(0\u002Froot)` mientras tu contenedor corre como 472, el problema está confirmado.",{"title":68,"body":69},"Inspeccionar la configuración del contenedor","```\ndocker inspect \u003Cnombre-contenedor> | grep -A5 'Mounts'\n```\nEste comando lista todos los bind-mounts y volúmenes nombrados activos.",{"type":35,"title":71,"body":72},"Corrección caso por caso: chown en el directorio del host","La corrección básica es un `chown` del directorio del host hacia el UID esperado por el contenedor. Aquí los comandos para las aplicaciones más comunes.",{"type":53,"steps":74},[75,78,81,84,87],{"title":76,"body":77},"Grafana (UID 472)","```\nmkdir -p \u002Fopt\u002Fgrafana\u002Fdata\nchown -R 472:472 \u002Fopt\u002Fgrafana\u002Fdata\n```\nEn tu `compose.yml`:\n```yaml\nvolumes:\n  - \u002Fopt\u002Fgrafana\u002Fdata:\u002Fvar\u002Flib\u002Fgrafana\n```",{"title":79,"body":80},"Nextcloud (UID 33, imagen Debian)","```\nmkdir -p \u002Fopt\u002Fnextcloud\u002F{data,config,apps}\nchown -R 33:33 \u002Fopt\u002Fnextcloud\u002Fdata\nchown -R 33:33 \u002Fopt\u002Fnextcloud\u002Fconfig\n```\nNota: la imagen Alpine usa UID 82. Verifica con `docker exec \u003Ccontenedor> id www-data` si no estás seguro de la variante.",{"title":82,"body":83},"Paperless-ngx (UID 1000)","```\nmkdir -p \u002Fopt\u002Fpaperless\u002F{consume,export,media,data}\nchown -R 1000:1000 \u002Fopt\u002Fpaperless\u002Fconsume\nchown -R 1000:1000 \u002Fopt\u002Fpaperless\u002Fexport\nchown -R 1000:1000 \u002Fopt\u002Fpaperless\u002Fmedia\nchown -R 1000:1000 \u002Fopt\u002Fpaperless\u002Fdata\n```",{"title":85,"body":86},"Immich (UID 1000)","```\nmkdir -p \u002Fopt\u002Fimmich\u002F{library,thumbnails,encoded-video,profile}\nchown -R 1000:1000 \u002Fopt\u002Fimmich\n```\nNota: las variables de entorno `PUID`\u002F`PGID` NO funcionan con las imágenes oficiales de Immich.",{"title":88,"body":89},"Verificar tras la corrección","```\nls -ln \u002Fopt\u002Fgrafana\u002Fdata\n```\nDebe mostrar `drwxr-xr-x 2 472 472 ...`. Luego reinicia el contenedor:\n```\ndocker compose restart grafana\ndocker logs grafana --tail 20\n```",{"type":35,"title":91,"body":92},"Variantes: bind-mounts, volúmenes nombrados y user:","El `chown` en el directorio del host funciona para bind-mounts, pero Docker ofrece otros enfoques según el contexto.\n\n**Directiva `user:` en compose.yml.** Algunas imágenes están diseñadas para aceptar un UID arbitrario vía `user:`. Esto evita el `chown` si tu directorio pertenece a tu usuario del host:\n```yaml\nservices:\n  app:\n    image: mi-imagen\n    user: \"1000:1000\"\n    volumes:\n      - \u002Fhome\u002Fuser\u002Fdata:\u002Fapp\u002Fdata\n```\nEste enfoque solo funciona si la imagen no requiere archivos internos con UID específico. Paperless-ngx soporta este modo; Grafana no.\n\n**Volúmenes nombrados de Docker.** Con un volumen Docker nombrado, Docker gestiona el directorio bajo `\u002Fvar\u002Flib\u002Fdocker\u002Fvolumes\u002F`. En la primera escritura, el directorio se crea con los permisos del proceso del contenedor — sin problemas de permisos al arrancar, pero migrar datos existentes requiere un paso de copia explícito.",{"type":35,"title":94,"body":95},"Casos NFS y montajes remotos","Los montajes NFS añaden una capa de complejidad: el servidor NFS aplica sus propias reglas de UID. Si el servidor exporta con `root_squash` (por defecto), el acceso root desde el cliente se reduce a `nobody`.\n\nSoluciones:\n1. Configurar la exportación NFS con `all_squash,anonuid=472,anongid=472` para Grafana.\n2. Usar `no_root_squash` solo si controlas completamente la red (riesgo de seguridad).\n3. Para CIFS\u002FSMB, pasar `uid=33,gid=33` en las opciones de montaje para Nextcloud.\n\nEn `\u002Fetc\u002Ffstab`:\n```\n\u002F\u002Fservidor\u002Fcompartido \u002Fopt\u002Fnextcloud\u002Fdata cifs uid=33,gid=33,credentials=\u002Fetc\u002Fcifs-creds,iocharset=utf8 0 0\n```",{"type":97,"title":98,"headers":99,"rows":103},"comparison","Métodos de corrección: comparación",[100,101,102],"Método","Ventajas","Riesgos \u002F Limitaciones",[104,108,112,116],[105,106,107],"chown UID:GID en directorio del host","Simple, universal, compatible con todas las imágenes","Hay que conocer el UID exacto; hay que repetirlo si se recrea el directorio",[109,110,111],"user: UID:GID en compose.yml","Sin chown; portable entre hosts","La imagen debe soportar UIDs arbitrarios; puede romper archivos internos",[113,114,115],"Volúmenes nombrados Docker","Permisos gestionados automáticamente en el primer arranque","Menos transparente; migrar datos existentes es más complejo",[117,118,119],"--privileged o chmod 777","Resuelve el problema de inmediato","PELIGRO: expone el host y todos sus procesos; nunca usar en producción",{"type":35,"title":121,"body":122},"Resolución de problemas: 4 errores clásicos con su mensaje exacto","Estos son los cuatro errores Docker más comunes relacionados con permisos, con el mensaje de error exacto y su solución.",{"type":42,"items":124},[125,126,127,128],"**`mkdir: cannot create directory '\u002Fvar\u002Flib\u002Fgrafana\u002Fplugins': Permission denied`** → El directorio del host no pertenece al UID 472. Aplica `chown -R 472:472 \u002Fopt\u002Fgrafana\u002Fdata`.","**`[Errno 13] Permission denied: '\u002Fusr\u002Fsrc\u002Fpaperless\u002Fmedia'`** → Paperless-ngx no puede escribir en su directorio media. Verifica que el bind-mount pertenece al UID 1000 en el host.","**`Could not create lock file \u002Fvar\u002Flib\u002Fgrafana\u002F.~lock.grafana.db`** → Grafana puede leer el directorio pero no escribir. Problema de permisos en archivos existentes: `chown 472:472 \u002Fopt\u002Fgrafana\u002Fdata\u002F*.db` o elimina el lock file.","**`chown: changing ownership of '\u002Fdata': Operation not permitted`** (al arrancar el contenedor) → La imagen intenta corregir permisos pero no puede porque no corre como root. Ejecuta el `chown` manualmente en el host ANTES de arrancar el contenedor.",{"type":130,"body":131},"tip","**SELinux y AppArmor: los flags `:z` y `:Z` en bind-mounts.** En sistemas con SELinux activo (CentOS, RHEL, Fedora), un bind-mount puede bloquearse aunque los permisos POSIX sean correctos. Docker proporciona dos sufijos: `:z` reetiqueta el contenido para compartirlo entre múltiples contenedores, y `:Z` para acceso privado (un solo contenedor). Ejemplo: `- \u002Fopt\u002Fgrafana\u002Fdata:\u002Fvar\u002Flib\u002Fgrafana:z`. Sin este flag en un sistema SELinux, obtendrás `Permission denied` incluso tras un `chown` correcto. Para verificar si SELinux está bloqueando: `ausearch -m AVC -ts recent | grep docker`.",{"type":35,"title":133,"body":134},"Conclusión","El `Permission denied` en los logs de Docker nunca es inevitable. La solución en tres comandos: `docker exec \u003Ccontenedor> id` para encontrar el UID, `ls -ln \u003Cdirectorio-host>` para confirmar el propietario actual, y `chown -R \u003CUID>:\u003CGID> \u003Cdirectorio-host>` para corregirlo. La regla de oro: crea los directorios del host con el propietario correcto antes de arrancar el contenedor, no después. En un VPS dedicado, esta disciplina evita el 90% de los incidentes de datos perdidos silenciosamente al reiniciar.","Un VPS listo para el self-hosting","Despliega tus aplicaciones Docker en un VPS ServOrbit con acceso root, IPv4 dedicada y snapshots automáticos. Desde 99 DH\u002Fmes.","Ver planes VPS","\u002Fvps-cloud",[140,162],{"id":141,"slug":142,"slugs":143,"title":147,"excerpt":148,"readTime":149,"views":150,"isPinned":19,"publishedAt":151,"updatedAt":152,"category":153,"categories":159,"featuredImage":29,"bgImage":30,"posterImage":161,"relatedSolution":29},369,"docker-secrets-produccion-proteger-credenciales-vps",{"fr":144,"en":145,"ar":146,"es":142},"docker-secrets-securite-vps-production","docker-secrets-production-protecting-credentials-on-vps","اسرار-docker-في-الانتاج-حماية-بيانات-الاعتماد-على-vps","Docker Secrets en producción: proteger credenciales en VPS","Gestiona secretos Docker en producción sin exponerlos en docker-compose.yml. Docker Secrets sin Swarm, .env.vault y SOPS: método y comparativa.",7,1,"2026-09-20T00:00:00+00:00","2026-09-20T21:13:51+00:00",{"id":154,"name":155,"slug":156,"color":157,"icon":158},8,"Seguridad y monitorización","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[160],{"id":154,"name":155,"slug":156,"color":157,"icon":158},"\u002Fblog\u002Fcovers\u002Fdocker-secrets-securite-vps-production-poster.svg",{"id":163,"slug":164,"slugs":165,"title":169,"excerpt":170,"readTime":171,"views":18,"isPinned":19,"publishedAt":172,"updatedAt":173,"category":174,"categories":175,"featuredImage":29,"bgImage":30,"posterImage":177,"relatedSolution":29},229,"checklist-docker-compose-en-produccion",{"fr":166,"en":167,"ar":168,"es":164},"docker-compose-production-checklist","docker-compose-in-production-10-point-checklist","docker-compose-في-الإنتاج-قائمة-التحقق-من-10-نقاط","Docker Compose en producción: checklist de 10 puntos","Checklist de Docker Compose en producción: 10 ajustes esenciales, health checks, secretos sin downtime, estrategia de rollback, solución de errores comunes.",12,"2026-08-06T00:00:00+00:00","2026-09-29T14:40:45+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[176],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Fdocker-compose-production-checklist-poster.svg",1790693328876]