Сбой резервного копирования при перемещении временного файла в директорию backups/default

Поддержка Самостоятельное хостинг
1

Создание временного файла резервной копии прошло успешно. Проблемы возникают при перемещении файла из /var/www/discourse/tmp/backups/default/ в
/var/www/discourse/public/backups/default/.

[2024-01-28 05:47:54] EXCEPTION: /var/www/discourse/lib/discourse.rb:137:in `exec': Failed to move database dump file.
mv: cannot move '/var/www/discourse/tmp/backups/default/2024-01-28-054559/dump.sql.gz' to '/var/www/discourse/public/backups/default/hungry-onion-2024-01-28-054559-v20230728055813.sql.gz': Permission denied

Как решить эту проблему?

Отдельно: связана ли эта проблема с тем, что я ранее создал папку /var/discourse/shared/standalone/backups/default/ (вне контейнера) вручную через командную строку при восстановлении резервной копии на новом экземпляре?

Текущие права доступа: drwxrwxr-x 2 1000 www-data 4096 Jan 27 17:35 default

2

Обычно эти два расположения находятся на одном диске, поэтому проблема, скорее всего, не в нехватке места на диске, а в правах доступа. Конечно, резервное копирование должно работать нормально, если у вас стандартная установка, поэтому, вероятно, проблема связана с вашим ручным созданием каталога.

Однако я проверил на своей машине, и в контейнере владение и права доступа выглядят следующим образом:

root@ubuntu-2gb-nbg1-1-app:/var/www/discourse# ls -ltrd /var/www/discourse/tmp/backups/default /var/www/discourse/public/backups/default
drwxr-xr-x 2 discourse www-data 4096 Jan 24 03:36 /var/www/discourse/tmp/backups/default
drwxr-xr-x 2 discourse www-data 4096 Jan 24 03:36 /var/www/discourse/public/backups/default
root@ubuntu-2gb-nbg1-1-app:/var/www/discourse# ls -nltrd /var/www/discourse/tmp/backups/default /var/www/discourse/public/backups/default
drwxr-xr-x 2 1000 33 4096 Jan 24 03:36 /var/www/discourse/tmp/backups/default
drwxr-xr-x 2 1000 33 4096 Jan 24 03:36 /var/www/discourse/public/backups/default
root@ubuntu-2gb-nbg1-1-app:/var/www/discourse# ls -nltrd /var/www/discourse/tmp/backups /var/www/discourse/public/backups
lrwxrwxrwx 1 0 0 19 Jan 10 15:26 /var/www/discourse/tmp/backups -> /shared/tmp/backups
lrwxrwxrwx 1 0 0 15 Jan 10 15:26 /var/www/discourse/public/backups -> /shared/backups
root@ubuntu-2gb-nbg1-1-app:/var/www/discourse# ls -nltrd /var/www/discourse/tmp /var/www/discourse/public
drwxr-xr-x 1 1000 1000 12288 Jan 10 15:31 /var/www/discourse/public
drwxr-xr-x 1 1000   33  4096 Jan 10 15:36 /var/www/discourse/tmp
root@ubuntu-2gb-nbg1-1-app:/var/www/discourse# ls -nltrd /var/www/discourse
drwxr-xr-x 1 1000 1000 4096 Jan 10 15:26 /var/www/discourse
root@ubuntu-2gb-nbg1-1-app:/var/www/discourse# ls -nltrd /shared/backups /shared/tmp/backups
drwxr-xr-x 3 1000 33 4096 Aug 15  2019 /shared/backups
drwxr-xr-x 3 1000 33 4096 Jan 10 15:36 /shared/tmp/backups
root@ubuntu-2gb-nbg1-1-app:/var/www/discourse# ls -nltrd /shared /shared/tmp
drwxr-xr-x 13    0  0 4096 Jan 27  2021 /shared
drwxr-xr-x  4 1000 33 4096 Jan 10 15:35 /shared/tmp

Пользователь с ID 1000 — это «discourse», а группа с ID 33 — «www-data». К сожалению, эта информация не даёт мне подсказки относительно вашей проблемы. Извините.

3

Может ли приложение внутри Docker видеть систему за пределами Docker? Я живу с убеждением, что так это сделать нельзя.

4

Вероятно. Попробуйте удалить её.

5

Я не совсем уверен, что произошло. Но вчера вечером система успешно выполнила резервное копирование. Сегодня я также вручную выполнил резервное копирование, и оно прошло успешно. Между этим временем и сейчас я не вносил никаких изменений в систему.

Ну, ничего страшного.