Dónde guarda archivos Nextcloud en Docker

Dónde almacena los archivos Nextcloud en Docker

Nextcloud en Docker almacena los archivos en un directorio de datos dentro del contenedor. La ubicación real en el servidor es el volumen o el montaje bind que haya asociado al contenedor. Con la imagen de linuxserver.io, lscr.io/linuxserver/nextcloud, los archivos de usuario se encuentran en /data. La instalación de Nextcloud y su config.php se encuentran en /config. Ambas son rutas del contenedor. Un comando muestra la ruta del host que hay detrás de ellas. El resto de esta guía aborda la parte más difícil de la pregunta: todo lo que el directorio de datos no contiene.

Fije la etiqueta de la imagen. Las rutas pertenecen a una imagen concreta, no a Nextcloud, y una etiqueta flotante puede cambiar sin aviso. En agosto de 2026, la etiqueta estable actual de esta imagen es 34.0.3.

services:
  nextcloud:
    image: lscr.io/linuxserver/nextcloud:34.0.3
    container_name: nextcloud
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
    volumes:
      - nextcloud_config:/config
      - nextcloud_data:/data
    ports:
      - 443:443
    restart: unless-stopped

  nextcloud-db:
    image: mariadb:11.8
    container_name: nextcloud-db
    environment:
      - MARIADB_ROOT_PASSWORD=${MARIADB_ROOT_PASSWORD}
      - MARIADB_DATABASE=nextcloud
      - MARIADB_USER=nextcloud
      - MARIADB_PASSWORD=${NEXTCLOUD_DB_PASSWORD}
    volumes:
      - nextcloud_db:/var/lib/mysql
    restart: unless-stopped

volumes:
  nextcloud_config:
  nextcloud_data:
  nextcloud_db:

Las dos contraseñas proceden de un archivo .env situado junto al archivo compose. Así no se incluyen en el propio archivo compose. La respuesta contiene tres volúmenes, pero sólo uno almacena los archivos de usuario.

Esas rutas del contenedor proceden de la documentación de esa imagen concreta. Otra imagen de Nextcloud puede organizar el sistema de archivos de otra forma y mantener la instalación bajo su propia raíz web. Por tanto, una ruta copiada de una publicación de un foro es sólo una suposición. Compruebe la información real en el contenedor que está ejecutando.

docker inspect nextcloud

La sección Mounts de esa salida muestra todos los montajes, con Source en el lado del host y Destination en el lado del contenedor. Esa lista responde a la pregunta para su configuración, independientemente de la imagen que haya elegido.

¿Cómo encuentro la ruta real del host detrás del volumen?

Docker administra los volúmenes con nombre, por lo que usted no elige su ruta. Debe consultarla.

docker volume ls
docker volume inspect nextcloud_nextcloud_data

El nombre es importante. Docker Compose antepone el nombre del proyecto a los nombres de los volúmenes. De forma predeterminada, el nombre del proyecto es el nombre del directorio que contiene el archivo de Compose. Por eso, un volumen escrito como nextcloud_data en el archivo normalmente existe como nextcloud_nextcloud_data en el disco. docker volume ls muestra los nombres reales. El resultado de inspect tiene este aspecto, abreviado:

[
    {
        "CreatedAt": "2026-08-18T09:12:44Z",
        "Driver": "local",
        "Mountpoint": "/var/lib/docker/volumes/nextcloud_nextcloud_data/_data",
        "Name": "nextcloud_nextcloud_data",
        "Scope": "local"
    }
]

Mountpoint es la respuesta. Léala desde el comando en lugar de asumirla, porque puede cambiar. En rootless Docker, toda la raíz de datos de Docker se encuentra dentro del directorio personal del usuario que ejecuta el daemon, por lo que esa ruta empieza en otra ubicación.

Un bind mount elimina esta duda. Escriba - /srv/nextcloud/data:/data en el archivo de Compose y la ruta del host será la que haya indicado; docker inspect la muestra como Source. La elección afecta a algo más que la ruta, porque los volúmenes con nombre y los bind mounts se comportan de forma distinta con respecto a la propiedad y las copias de seguridad.

Por qué el directorio de datos no es una copia de seguridad

El manual de Nextcloud indica cinco elementos que debe conservar una copia de seguridad: el directorio de configuración, el directorio de aplicaciones personalizadas, el directorio de datos, el directorio del tema y la base de datos. Con esta imagen, los directorios de configuración, aplicaciones y tema se encuentran bajo /config, mientras que la base de datos se ejecuta en su propio contenedor con su propio volumen. Si copia /data por separado, sólo habrá guardado la parte menos importante del problema.

La base de datos es importante porque la interfaz web nunca muestra un directorio. Muestra filas de la caché de archivos. Por eso el manual indica que debe ejecutar un análisis después de copiar archivos manualmente en el directorio de datos. Si restaura /data junto a una base de datos vacía, tendrá bytes sin índice: no habrá usuarios, recursos compartidos ni archivos en la lista. Si restaura la base de datos junto a un /data vacío, cada fila apuntará a un archivo que ya no existe.

config.php contiene las credenciales de la base de datos y los dominios de confianza. También contiene el identificador de la instancia, que es el nombre del directorio de datos de la aplicación dentro del directorio de datos. Consulte la instancia en ejecución en lugar de confiar en cualquiera de estos valores memorizados.

docker exec -it nextcloud occ config:system:get datadirectory
docker exec -it nextcloud occ config:system:get instanceid

El primer comando muestra el directorio de datos que usa realmente esta instancia, que aquí es /data. Esta imagen incluye un envoltorio occ en el PATH, así que ejecútelo directamente mediante docker exec. No copie la forma más larga sudo y php occ del manual de Nextcloud. Esa forma está escrita para una instalación fuera de un contenedor.

¿Qué está llenando silenciosamente el volumen de datos?

Las vistas previas y el historial de cada usuario se almacenan en el mismo volumen que los archivos. Ninguno de los dos aparece en el indicador de almacenamiento que el usuario ve en la interfaz web.

• Las vistas previas son miniaturas generadas. Se almacenan en la carpeta de datos de la aplicación dentro del directorio de datos, con el nombre appdata_ seguido del identificador de la instancia.
• Los archivos eliminados permanecen en la papelera. trashbin_retention_obligation tiene auto de forma predeterminada. Esto los conserva durante 30 días y después sólo los elimina cuando se necesita espacio. Los archivos eliminados siguen contando para la cuota del usuario. Cuando se supera la cuota, se ignora la configuración de retención y la papelera se depura hasta que la cuota vuelve a cumplirse.
• Las versiones antiguas también permanecen. versions_retention_obligation tiene auto de forma predeterminada. La aplicación Versions nunca utiliza más del 50% del espacio libre actual de un usuario. Cuando depura versiones, elimina primero las más antiguas y conserva las dos más recientes. Una versión cuyo nombre haya especificado manualmente un usuario nunca se elimina.

Mida antes de eliminar nada.

docker exec -it nextcloud sh -c 'du -sh /data/*'
docker exec -it nextcloud sh -c 'du -sh /data/appdata_*'

La primera línea muestra un número por cada carpeta de usuario y otro para la carpeta de datos de la aplicación. Si el número de los datos de la aplicación es grande, la causa son las vistas previas. Los comandos de limpieza siguientes están documentados y todos destruyen datos de forma intencionada.

docker exec -it nextcloud occ trashbin:cleanup --all-users
docker exec -it nextcloud occ versions:cleanup alice
docker exec -it nextcloud occ preview:cleanup

preview:cleanup elimina todas las vistas previas generadas. Nextcloud las vuelve a generar cuando los usuarios abren esos archivos. Por eso, el espacio vuelve a ocuparse gradualmente y la CPU debe procesarlas de nuevo. Si el volumen sólo es una parte de un problema de disco más amplio, las imágenes antiguas y la caché de compilación obsoleta suelen ser la otra parte.

¿Por qué los archivos que copio en el host no aparecen en Nextcloud?

Porque Nextcloud lee la caché de archivos en la base de datos, no el directorio. La copia creó un archivo en el disco sin una fila correspondiente, por lo que la interfaz web no tiene nada que mostrar. El manual describe exactamente este caso: es necesario ejecutar un análisis después de copiar archivos directamente en el directorio de datos.

docker exec -it nextcloud occ files:scan --path="/alice/files/Photos"
docker exec -it nextcloud occ files:scan --unscanned -v
docker exec -it nextcloud occ files:scan --all

El argumento --path también muestra la estructura del directorio de datos: cada usuario tiene una carpeta con su nombre de usuario, y files dentro de ella contiene lo que ve en la interfaz web. Analice una ruta cuando sepa dónde se copiaron los archivos. --all recorre todos los usuarios y tarda mucho en una instancia grande. --unscanned sólo procesa los archivos marcados como aún no analizados por completo. -v muestra cada archivo mientras se procesa. Esta es la diferencia entre un comando que parece bloqueado y uno cuyo progreso puede supervisar.

La propiedad determina si el análisis es suficiente. Si el usuario del contenedor no puede escribir en un archivo, este se indexa, pero después no se puede mover. Por eso el listado parece correcto, mientras que el cambio de nombre o la eliminación desde la interfaz web fallan.

¿Por qué fallan las escrituras después de configurar PUID y PGID?

Porque el kernel compara números, no nombres. PUID y PGID establecen el identificador numérico de usuario (uid) y el identificador numérico de grupo (gid) con los que se ejecuta el proceso del contenedor. Cada archivo del host también tiene un propietario numérico. Si los dos números no coinciden, la escritura se rechaza, independientemente de cómo sean los nombres en cada lado.

docker exec -it nextcloud id abc
sudo ls -ln /var/lib/docker/volumes/nextcloud_nextcloud_data/_data

id abc muestra el uid y el gid que usa realmente el contenedor. Son los valores de PUID y PGID que configuró. ls -ln muestra los propietarios numéricos, y -n es importante: ls -l sin opciones traduce esos números mediante la lista de usuarios del host y muestra un nombre que no significa nada dentro del contenedor. Compare los dos números.

A continuación, pruebe la escritura en lugar de hacer suposiciones.

docker exec -u abc -it nextcloud touch /data/writetest

Un Permission denied que nombre /data confirma el resultado. Corrija la propiedad desde dentro del contenedor y vuelva a ejecutar la misma prueba.

docker exec -u 0 -it nextcloud chown -R abc:abc /data
docker exec -u abc -it nextcloud touch /data/writetest
docker exec -u abc -it nextcloud rm /data/writetest

Hágalo desde dentro por un motivo. Con Docker sin root, los identificadores de usuario del contenedor se asignan mediante el rango subordinado de /etc/subuid, por lo que el uid 1000 dentro del contenedor corresponde a un uid mucho mayor en el host. Un chown 1000:1000 ejecutado en el host establece entonces un propietario que el contenedor no puede usar, y la escritura sigue fallando. Ejecutar chown dentro del contenedor utiliza la misma asignación que el propio proceso de Nextcloud, por lo que los números coinciden de forma garantizada. Por eso PUID y PGID deben coincidir con el propietario del disco antes de investigar cualquier otra cosa.

¿Cómo hago una copia de seguridad para que la restauración funcione realmente?

Obtenga la base de datos y las carpetas en el mismo momento. El modo de mantenimiento impide los inicios de sesión, por lo que ninguna carga se incorpora entre el volcado y la copia.

docker exec -it nextcloud occ maintenance:mode --on
docker exec nextcloud-db mariadb-dump --single-transaction -u nextcloud -p"$NEXTCLOUD_DB_PASSWORD" nextcloud > nextcloud-sqlbkp.sql
docker run --rm -v nextcloud_nextcloud_data:/data:ro -v "$PWD":/backup alpine:3.22 tar czf /backup/nextcloud-data.tgz -C /data .
docker run --rm -v nextcloud_nextcloud_config:/config:ro -v "$PWD":/backup alpine:3.22 tar czf /backup/nextcloud-config.tgz -C /config .
docker exec -it nextcloud occ maintenance:mode --off

Observe lo que no incluye la línea del volcado: una opción -t. Un TTY reescribe los finales de línea, y un volcado SQL que ha pasado por uno queda dañado de una forma que sólo se detecta durante la restauración. Observe también que una contraseña escrita en la línea de comandos aparece en la salida de ps mientras se ejecuta el comando, así que léala desde el archivo .env en el shell en lugar de escribirla. Las imágenes de base de datos antiguas incluyen mysqldump en lugar de mariadb-dump, y el manual documenta ambas opciones.

Para restaurar, cargue el volcado en una base de datos vacía, descomprima ambos archivos en volúmenes nuevos, inicie los contenedores y, después, desactive el modo de mantenimiento. Si las carpetas y el volcado proceden de momentos distintos, la caché de archivos y el disco no coinciden, y occ files:scan --all sólo repara una dirección. Encuentra archivos que existen sin una fila. No puede recuperar un archivo al que apunta una fila.

Mantenga el resultado fuera del servidor. Una copia almacenada dentro del mismo VPS se pierde con el VPS. Por eso restic en un repositorio externo forma parte de este proceso y por eso una instantánea del proveedor es una herramienta distinta de una copia de seguridad. Si todavía está configurando la pila, una instalación completa de Nextcloud en un VPS cubre el reverse proxy y el certificado TLS (transport layer security) que esta guía no incluye.

FAQ

¿Dónde está el directorio de datos de Nextcloud en un contenedor Docker?

Con la imagen de linuxserver.io, está en /data dentro del contenedor, y la instalación con config.php se encuentra en /config. Esas son rutas del contenedor. Para obtener la ruta del host, ejecute docker inspect nextcloud y lea el valor de Source en la sección Mounts, o ejecute docker volume inspect en el volumen y lea Mountpoint. Otras imágenes de Nextcloud usan rutas de contenedor diferentes. Consulte la documentación de la etiqueta que fijó y confirme el resultado con docker exec -it nextcloud occ config:system:get datadirectory.

¿Por qué los archivos que copio en el volumen no aparecen en Nextcloud?

Nextcloud muestra las entradas de la caché de archivos de la base de datos en lugar de leer el directorio. Por eso, un archivo que llega sin pasar por Nextcloud no tiene ninguna entrada y permanece invisible. Ejecute docker exec -it nextcloud occ files:scan --path="/alice/files/Photos" para una carpeta o occ files:scan --all para todos los usuarios. Si los archivos aparecen, pero después no se pueden mover ni eliminar, la causa son los permisos de propietario: el usuario del contenedor debe poder escribir en ellos.

¿Basta con copiar el volumen de datos para restaurar Nextcloud?

No. El volumen de datos contiene el contenido de los archivos. La base de datos contiene el índice de archivos, además de los usuarios y los recursos compartidos, y config.php contiene las credenciales de la base de datos y el ID de la instancia. Una restauración funcional necesita la carpeta de datos, la carpeta de configuración, la base de datos y las carpetas de aplicaciones y temas personalizados si las usa. Obtenga todos estos elementos del mismo momento, porque una base de datos más reciente que los archivos apunta a archivos que no existen.

¿Por qué mi volumen de datos es mucho más grande que los archivos que ven mis usuarios?

Las vistas previas, los archivos eliminados y las versiones antiguas se almacenan en el mismo volumen, y ninguno aparece en la cifra que ve el usuario. Mida el uso con docker exec -it nextcloud sh -c 'du -sh /data/*'. La papelera conserva los archivos eliminados durante 30 días de forma predeterminada y sólo los elimina antes cuando se necesita espacio. La aplicación Versions puede usar hasta la mitad del espacio libre que tiene actualmente un usuario. Límpielos con occ trashbin:cleanup --all-users, occ versions:cleanup alice y occ preview:cleanup. Tenga en cuenta que las vistas previas volverán a crecer cuando los usuarios abran sus archivos.

¿Puedo mover el directorio de datos de Nextcloud a otro disco?

Monte la nueva ubicación en la misma ruta del contenedor en lugar de cambiar la ruta que conoce Nextcloud. Detenga el contenedor y copie el contenido antiguo al disco nuevo conservando el propietario (cp -a o rsync -aAX). Después, cambie el volumen o el bind mount para que apunte a la nueva ubicación en el archivo compose y vuelva a iniciar el contenedor. Nextcloud seguirá viendo /data, por lo que no será necesario cambiar ninguna entrada de la base de datos. Verifique el resultado con docker exec -it nextcloud occ config:system:get datadirectory y con una carga de prueba.