Daily borg backup breaks the interaction of external disks #5309
-
Steps to reproduce
Expected behaviorThe disks should display and work normally in nextcloud Actual behaviorDisk connection error in nextcloud Other informationIf you stop all containers and start them from the AIO interface, the disks show up normally again and everything works in nextcloud. |
Beta Was this translation helpful? Give feedback.
Replies: 33 comments
-
Hi, I fear I cannot reproduce the issue. So I need more information like logs, detailed reproduction steps, etc. |
Beta Was this translation helpful? Give feedback.
-
Also, please fill out the whole bug report template: https://raw.githubusercontent.com/nextcloud/all-in-one/main/.github/ISSUE_TEMPLATE/Bug_report.md |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Thanks for the information! How are the drives mounted? Via /etc/fstab or via a different way? |
Beta Was this translation helpful? Give feedback.
-
Disks are mounted via systemd (rclone is used)
|
Beta Was this translation helpful? Give feedback.
-
Can you mount them via /etc/fstab? If that makes it work, it is most likely a systemd startup issue: for example the drives need to be mounted before docker starts. |
Beta Was this translation helpful? Give feedback.
-
During autobacks, disks are not unmounted in the system. They remain mounted, so they are not affected in any way. For example, immich running in docker continues to use disks. |
Beta Was this translation helpful? Give feedback.
-
Hm... Can you run |
Beta Was this translation helpful? Give feedback.
-
And yes, I checked. Mounted disks manually, mounted them in /etc/fstab - the problem remains only in nextcloud and only when a scheduled backup is performed. If the backup is done manually from the AIO interface, if you stop the containers in AIO and then start them, everything works as it should.
|
Beta Was this translation helpful? Give feedback.
-
I fear I cannot explain the behaviour - restarting the nextcloud container should not suddenly make it work if the drives are correctly mounted already before the container is started. |
Beta Was this translation helpful? Give feedback.
-
I don't understand the reasoning behind it either.
then everything works again Could you please tell me where to see what exactly is being backed up (which folders, disks)? Maybe I can configure borgbackup in the system then |
Beta Was this translation helpful? Give feedback.
-
Can you please first try to add
Yes, this points towards a mounting order issue as I pointed out above...
You can inspect the borgbackup container via |
Beta Was this translation helpful? Give feedback.
-
BTW, I just googled a bit around and found this wiki: https://github.com/rclone/rclone/wiki/Systemd-rclone-mount. Maybe it helps you to figure things out. |
Beta Was this translation helpful? Give feedback.
-
Yeah, I saw that, too, but this is no different from running it manually |
Beta Was this translation helpful? Give feedback.
-
Can you maybe test if a different kind of mount works via fstab like eg a local disk as all your mounts are currently using rclone iirc? |
Beta Was this translation helpful? Give feedback.
-
As a temporary solution, I have added a stop and start container to the cron (a few minutes after the backup). checked - it works. |
Beta Was this translation helpful? Give feedback.
-
Hi, did you already open a thread in a rclone and/or docker forum for further help on this? |
Beta Was this translation helpful? Give feedback.
-
Hello, didn't create on those forums. Still I have not had any problems with other containers in docker and rclone, only AIO and only when running a backup. Since I added a task to the cron job to stop and start the container about 10 minutes after the scheduled backup (this happens when the cloud is not in use), the cloud operation is now unaffected by this backup.
I saw that the backup container is also used by fuse (and rclone mounts with fuse).
Come to think of it, maybe it has some effect and changes the permissions in the container |
Beta Was this translation helpful? Give feedback.
-
Lets try the following. Can you run the following and post the output here?
|
Beta Was this translation helpful? Give feedback.
-
Hello, of course.
|
Beta Was this translation helpful? Give feedback.
-
All right. Then another test.
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
Ah wait, you need to wait for the borgbackup container to stop before running the additonal commands. So simply add a sleep after starting the borgbackup container |
Beta Was this translation helpful? Give feedback.
-
How long do we have to wait? I can run it in the portainer, wait for it to stop and then run additional commands. How do you like this option? |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
I fear I am for now out ideas how to debug this further and especially what could cause this.
This still points towards the rclone mount not behaving correctly. So I still think it makes sense to open a thread there. |
Beta Was this translation helpful? Give feedback.
-
It seems to me that after a standard auto backup, nextcloud does not correctly determine the rights to folders and files on disks mounted using rclone. But if after this you stop and start the nextcloud container, then the rights are determined correctly, and such disks work in nextcloud, as in other docker containers. During the time I added a task to stop and start the container to cron, there were no problems with disks. This is, of course, a "crutch", but it works. About opening a report in rclone. Since such issues do not arise with several other containers, but only in nextcloud aio and then with auto backup, I just don’t know what to describe there, because the issue is specific only to nextcloud. There may be a problem with the application External storage? |
Beta Was this translation helpful? Give feedback.
-
Hello. I don’t know what helped, but the problem seems to have disappeared (I checked yesterday and today by disabling the cron job). Upgrading to v9.5.1 may have helped What extra I did: I'll keep watching, but I think we can close the issue. Thanks |
Beta Was this translation helpful? Give feedback.
-
Hi thanks for the feedback and for leeting me know.
This sounds like it was indeed the culprit in the config. Closing then and moving to discussions. |
Beta Was this translation helpful? Give feedback.
Hello.
I don’t know what helped, but the problem seems to have disappeared (I checked yesterday and today by disabling the cron job).
Upgrading to v9.5.1 may have helped
What extra I did:
Unmounted the disks, set permissions on the mount folders again, changed the logic in the automount by deleting the
TimeoutIdleSec=600
After that, remounted the disks.
Set a new schedule for the backup, checked, disks in nexcloud are working fine. Waited 10+ hours, changed the schedule again, checked after the autobackup - everything works.
I'll keep watching, but I think we can close the issue.
Thanks