Где Nextcloud хранит файлы в Docker

Где Nextcloud в Docker хранит файлы

Nextcloud в Docker хранит файлы в каталоге данных внутри контейнера, а их фактическое расположение на сервере определяется томом или bind mount, который вы к нему подключили. В образе от linuxserver.io, lscr.io/linuxserver/nextcloud, пользовательские файлы находятся в /data, а сама установка Nextcloud с её config.php — в /config. Оба этих пути являются путями внутри контейнера. Одна команда выводит путь на хосте, соответствующий этим директориям, а остальная часть этого руководства посвящена более сложной половине вопроса: всему тому, что не входит в каталог данных.

Фиксируйте тег образа. Пути зависят от конкретного образа, а не от самого Nextcloud, и «плавающий» тег может измениться без вашего ведома. По состоянию на август 2026 года текущим стабильным тегом для этого образа является 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:

Два пароля берутся из файла .env, расположенного рядом с файлом compose, поэтому они не попадают в сам compose-файл. Таким образом, в ответе указаны три тома, и только один из них содержит пользовательские файлы.

Эти пути внутри контейнера взяты из документации к конкретному образу. Другой образ Nextcloud может иметь иную структуру файловой системы и хранить установку в собственном корневом веб-каталоге, поэтому путь, скопированный с форума, — это лишь догадка. Узнайте достоверную информацию из того контейнера, который вы используете.

docker inspect nextcloud

Секция Mounts в выводе этой команды перечисляет все точки монтирования, где Source — это путь на хосте, а Destination — путь внутри контейнера. Этот список дает ответ на вопрос для вашей конфигурации, независимо от того, какой образ вы выбрали.

Как узнать реальный путь к хосту для тома?

Именованный том управляется Docker, поэтому вы не выбираете его путь. Вы запрашиваете его.

docker volume ls
docker volume inspect nextcloud_nextcloud_data

Имя имеет значение. Docker Compose добавляет к именам томов префикс с названием проекта, которое по умолчанию совпадает с именем каталога, содержащего ваш файл compose. Поэтому том, указанный как nextcloud_data в файле, обычно существует как nextcloud_nextcloud_data на диске. docker volume ls показывает реальные имена. Вывод команды inspect выглядит примерно так (сокращенно):

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

Mountpoint — это и есть ответ. Получайте его из команды, а не делайте предположений, так как путь может измениться. В режиме rootless Docker весь корневой каталог данных Docker находится внутри домашней директории пользователя, запустившего демон, поэтому путь начинается в другом месте.

Bind mount снимает этот вопрос. Укажите - /srv/nextcloud/data:/data в файле compose, и путь на хосте будет именно тем, который вы ввели, что docker inspect отображает как Source. Этот выбор меняет не только путь, так как именованные тома и bind mounts ведут себя по-разному в вопросах владения файлами и резервного копирования.

Почему каталог данных не является резервной копией

В руководстве Nextcloud перечислены пять компонентов, которые должны входить в резервную копию: папка конфигурации, папка пользовательских приложений, папка данных, папка тем и база данных. В данном образе папки конфигурации, приложений и тем находятся в /config, а база данных работает в отдельном контейнере со своим томом. Если скопировать только /data, вы сохраните наименее важную часть системы.

База данных критически важна, так как веб-интерфейс не отображает содержимое каталогов напрямую. Он выводит строки из файлового кэша, поэтому руководство предписывает запускать сканирование после ручного копирования файлов в каталог данных. Если восстановить /data при пустой базе данных, вы получите набор байтов без индекса: без пользователей, без общих ресурсов и без списка файлов. Если восстановить базу данных при пустом /data, каждая строка будет указывать на отсутствующий файл.

В config.php хранятся учетные данные базы данных и доверенные домены. Там же находится идентификатор экземпляра (instance id), который является именем папки данных приложения внутри каталога данных. Запрашивайте эти данные у работающего экземпляра, а не полагайтесь на значения, сохраненные в памяти.

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

Первая команда выводит путь к каталогу данных, который фактически использует данный экземпляр; в нашем случае это /data. Этот образ содержит обертку occ в пути, поэтому запускайте её напрямую через docker exec. Не используйте более длинные формы sudo и php occ из руководства Nextcloud, так как они предназначены для установки вне контейнера.

Что незаметно заполняет том с данными?

Миниатюры и история действий пользователей хранятся в том же томе, что и файлы, но ни то, ни другое не учитывается в показателе занятого места, который пользователь видит в веб-интерфейсе.

• Миниатюры — это созданные системой уменьшенные копии изображений. Они находятся в папке app data внутри директории с данными, имя которой начинается с appdata_, за которым следует идентификатор экземпляра.
• Удаленные файлы остаются в корзине. Параметр trashbin_retention_obligation по умолчанию имеет значение auto: файлы хранятся 30 дней и удаляются после этого срока только в том случае, если требуется свободное место. Удаленные файлы по-прежнему учитываются в квоте пользователя. Если квота превышена, настройки хранения игнорируются, и корзина очищается до тех пор, пока объем данных не уложится в квоту.
• Старые версии файлов также сохраняются. Параметр versions_retention_obligation по умолчанию имеет значение auto. Приложение Versions никогда не использует более 50% свободного места пользователя. При очистке оно удаляет самые старые версии в первую очередь, сохраняя две последние. Версии, которые пользователь пометил вручную, не удаляются никогда.

Перед удалением любых данных выполните замеры.

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

Первая строка выводит по одному числу для каждой папки пользователя и папки app data. Если значение для app data велико, причина в миниатюрах. Команды очистки, приведенные ниже, задокументированы, и каждая из них предназначена для целенаправленного удаления данных.

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 удаляет все созданные миниатюры. Nextcloud создаст их заново, когда пользователи откроют соответствующие файлы, поэтому место будет освобождаться постепенно, а нагрузка на CPU возрастет. Если том — лишь часть более масштабной проблемы с дисковым пространством, то старые изображения и устаревший кэш сборки, как правило, являются второй его частью.

Почему файлы, скопированные на хост, не отображаются в Nextcloud?

Nextcloud считывает информацию о файлах из кэша в базе данных, а не напрямую из файловой системы. При копировании вы создали файл на диске, но в базе данных для него нет соответствующей записи, поэтому веб-интерфейс не может его отобразить. В документации описан этот случай: после прямого копирования файлов в директорию данных необходимо запустить сканирование.

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

Аргумент --path также показывает структуру внутри директории данных: для каждого пользователя создана папка с именем его учетной записи, а files внутри неё содержит то, что пользователь видит в веб-интерфейсе. Выполняйте сканирование конкретного пути, если знаете, куда были помещены файлы. --all обходит всех пользователей и занимает много времени на крупных инстансах. --unscanned затрагивает только те файлы, которые помечены как еще не полностью просканированные. -v выводит имя каждого файла по мере его обработки; это позволяет отличить зависшую команду от процесса, за которым можно наблюдать.

Права доступа определяют, будет ли достаточно одного сканирования. Если файл недоступен для записи пользователю, от имени которого работает контейнер, он будет проиндексирован, но его перемещение станет невозможным. В результате список файлов будет выглядеть корректно, однако переименование или удаление через веб-интерфейс завершится ошибкой.

Почему запись завершается ошибкой после установки PUID и PGID?

Потому что ядро сравнивает числа, а не имена. PUID и PGID задают числовой идентификатор пользователя (uid) и идентификатор группы (gid), от имени которых выполняется процесс в контейнере. Каждый файл на хосте также имеет числового владельца. Если эти числа не совпадают, в записи будет отказано, независимо от того, как имена выглядят с обеих сторон.

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

id abc выводит uid и gid, которые реально использует контейнер; это те самые PUID и PGID, которые вы установили. ls -ln выводит числовых владельцев, и здесь важен -n: обычный ls -l транслирует эти числа через список пользователей хоста и показывает имя, которое внутри контейнера ничего не значит. Сравните эти два числа.

Затем протестируйте запись, вместо того чтобы гадать.

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

Permission denied с указанием /data служит подтверждением. Исправьте владельца изнутри контейнера, а затем снова запустите тот же тест.

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

Делайте это изнутри не просто так. В rootless Docker идентификаторы пользователей контейнера отображаются через подчиненный диапазон в /etc/subuid, поэтому uid 1000 внутри контейнера соответствует гораздо большему uid на хосте. Команда chown 1000:1000 на стороне хоста в таком случае установит владельца, которого контейнер не сможет использовать, и запись по-прежнему будет завершаться ошибкой. Запуск chown внутри контейнера проходит через то же отображение, которое использует сам процесс Nextcloud, поэтому числа совпадают по определению. Именно поэтому PUID и PGID должны совпадать с владельцем на диске, прежде чем вы начнете отладку чего-либо еще.

Как выполнять резервное копирование, чтобы восстановление гарантированно сработало?

Забирайте базу данных и папки в один и тот же момент времени. Режим обслуживания (maintenance mode) блокирует вход в систему, поэтому новые загрузки не попадут в хранилище между созданием дампа и копированием файлов.

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

Обратите внимание, чего нет в команде создания дампа: флага -t. TTY переписывает символы переноса строк, и SQL-дамп, прошедший через него, будет поврежден так, что вы узнаете об этом только при попытке восстановления. Также учтите, что пароль в командной строке виден в выводе ps во время выполнения команды, поэтому считывайте его в оболочку из файла .env, а не вводите вручную. В старых образах баз данных поставляется mysqldump вместо mariadb-dump, и в документации описаны оба варианта.

Для восстановления загрузите дамп в пустую базу данных, распакуйте оба архива в новые тома, запустите контейнеры, а затем отключите режим обслуживания. Если папки и дамп были получены в разное время, файловый кэш и диск будут расходиться, а occ files:scan --all исправляет ситуацию только в одну сторону. Утилита находит файлы, для которых нет записи в базе, но не может вернуть файл, на который указывает существующая запись.

Храните результат вне сервера. Копия, которая находится на том же VPS, погибнет вместе с ним, поэтому использование restic для внешнего репозитория является обязательной частью этого процесса, а снимки (snapshots) провайдера — это не то же самое, что резервная копия. Если вы только строите стек, полная установка Nextcloud на VPS охватывает настройку обратного прокси и сертификатов TLS (transport layer security), которые не рассматриваются в этом руководстве.

FAQ

Где находится каталог данных Nextcloud в Docker-контейнере?

В образе от linuxserver.io это /data внутри контейнера, а установка с помощью config.php находится в /config. Это пути внутри контейнера. Чтобы узнать путь на хосте, выполните docker inspect nextcloud и найдите значение Source в секции Mounts, либо выполните docker volume inspect для тома и прочитайте Mountpoint. Другие образы Nextcloud используют иные пути, поэтому сверьтесь с документацией для используемого тега и подтвердите путь с помощью docker exec -it nextcloud occ config:system:get datadirectory.

Почему файлы, которые я копирую в том, не отображаются в Nextcloud?

Nextcloud считывает записи из кэша файлов в своей базе данных, а не сканирует каталог напрямую. Файл, добавленный в обход Nextcloud, не имеет записи в БД и остается невидимым. Выполните docker exec -it nextcloud occ files:scan --path="/alice/files/Photos" для одной папки или occ files:scan --all для всех пользователей. Если файлы появились, но их невозможно переместить или удалить, причина в правах доступа: пользователь, от имени которого работает контейнер, должен иметь права на запись.

Достаточно ли копии тома с данными для восстановления Nextcloud?

Нет. Том с данными содержит только содержимое файлов. База данных хранит индекс файлов, информацию о пользователях и общих ресурсах, а config.php содержит учетные данные для доступа к базе данных и идентификатор экземпляра (instance id). Для корректного восстановления необходимы папка с данными, папка конфигурации, база данных, а также папки с пользовательскими приложениями и темами, если вы их используете. Создавайте резервные копии всех этих компонентов одновременно, так как база данных, которая новее файлов, будет ссылаться на несуществующие объекты.

Почему мой том с данными занимает гораздо больше места, чем файлы, которые видят пользователи?

Превью, удаленные файлы и старые версии хранятся в том же томе, но не учитываются в статистике пользователя. Проверьте размер с помощью docker exec -it nextcloud sh -c 'du -sh /data/*'. Корзина хранит удаленные файлы по умолчанию 30 дней и очищает их раньше только при нехватке места, а приложение Versions может занимать до половины свободного места пользователя. Очистите их с помощью occ trashbin:cleanup --all-users, occ versions:cleanup alice и occ preview:cleanup. Учтите, что превью будут создаваться заново по мере того, как пользователи открывают свои файлы.

Можно ли переместить каталог данных Nextcloud на другой диск?

Примонтируйте новое расположение по тому же пути внутри контейнера, вместо того чтобы менять путь в настройках Nextcloud. Остановите контейнер, скопируйте старое содержимое на новый диск с сохранением прав доступа (cp -a или rsync -aAX), укажите новое расположение в томе или bind mount в вашем compose-файле и запустите контейнер снова. Nextcloud по-прежнему будет видеть /data, поэтому записи в базе данных менять не нужно. Проверьте результат с помощью docker exec -it nextcloud occ config:system:get datadirectory и тестовой загрузки файла.