invalid cross-device link when using split Docker volume mapping on Unraid #68

Closed
opened 2026-04-05 16:15:41 +02:00 by MrUnknownDE · 0 comments
Owner

Originally created by @Gekko23 on 3/13/2026

Environment

  • Platform: Unraid (Community Apps)
  • Databasus version: latest
  • Deployment: Docker container with split volume mapping

Setup / Volume Mapping

To separate backup files from appdata, the following split volume mapping was configured:

Host Path Container Path
/mnt/user/appdata/databasus/data /databasus-data
/mnt/user/Backups/Terra/databasus-bkp /databasus-data/backups
/mnt/user/Backups/Terra/databasus-temp /databasus-data/temp

Problem

Every backup attempt fails with the following error:

save to storage: failed to move file from temp to backups: rename /databasus-data/temp/<backup-file> /databasus-data/backups/<backup-file>: invalid cross-device link

Investigation

Extensive debugging was done to rule out filesystem-level causes:

1. Both paths report the same filesystem inside the container:

$ docker exec Databasus df /databasus-data/backups /databasus-data/temp
Filesystem     1K-blocks       Used  Available Use% Mounted on
shfs         68351515732 57079736536 11271779196  84% /databasus-data/backups
shfs         68351515732 57079736536 11271779196  84% /databasus-data/temp

2. Both host paths resolve to the same physical disk:

$ ls -la /mnt/disk*/Backups/Terra/
databasus-bkp/   # same disk
databasus-temp/  # same disk

3. A manual mv between the two container paths succeeds without error:

$ docker exec Databasus sh -c "touch /databasus-data/temp/testfile && mv /databasus-data/temp/testfile /databasus-data/backups/testfile"
# No output, no error — file arrived successfully in /databasus-data/backups/

4. Active mounts as reported by docker inspect:

{
  "Source": "/mnt/user/Backups/Terra/databasus-bkp",
  "Destination": "/databasus-data/backups"
},
{
  "Source": "/mnt/user/Backups/Terra/databasus-temp",
  "Destination": "/databasus-data/temp"
},
{
  "Source": "/mnt/user/appdata/databasus/data",
  "Destination": "/databasus-data"
}

Conclusion

Since a manual mv (which uses the same rename syscall) works fine between the two paths inside the container, the issue appears to be specific to how Databasus internally performs the rename operation — possibly using a lower-level approach that does not behave the same way under Unraid's shfs (a FUSE-based virtual filesystem that merges multiple physical disks) when volumes are split across separate bind mounts.

Request

Could you investigate how the temp-to-backups file move is implemented internally? A fallback using a copy-then-delete approach instead of a direct rename syscall would resolve the issue in environments where rename across bind mounts fails despite the paths appearing to be on the same filesystem.

Happy to provide any additional information or run further tests if needed.

*Originally created by @Gekko23 on 3/13/2026* ## Bug Report: `invalid cross-device link` when using split Docker volume mapping on Unraid ### Environment - **Platform:** Unraid (Community Apps) - **Databasus version:** latest - **Deployment:** Docker container with split volume mapping ### Setup / Volume Mapping To separate backup files from appdata, the following split volume mapping was configured: | Host Path | Container Path | |---|---| | `/mnt/user/appdata/databasus/data` | `/databasus-data` | | `/mnt/user/Backups/Terra/databasus-bkp` | `/databasus-data/backups` | | `/mnt/user/Backups/Terra/databasus-temp` | `/databasus-data/temp` | ### Problem Every backup attempt fails with the following error: ``` save to storage: failed to move file from temp to backups: rename /databasus-data/temp/<backup-file> /databasus-data/backups/<backup-file>: invalid cross-device link ``` ### Investigation Extensive debugging was done to rule out filesystem-level causes: **1. Both paths report the same filesystem inside the container:** ``` $ docker exec Databasus df /databasus-data/backups /databasus-data/temp Filesystem 1K-blocks Used Available Use% Mounted on shfs 68351515732 57079736536 11271779196 84% /databasus-data/backups shfs 68351515732 57079736536 11271779196 84% /databasus-data/temp ``` **2. Both host paths resolve to the same physical disk:** ``` $ ls -la /mnt/disk*/Backups/Terra/ databasus-bkp/ # same disk databasus-temp/ # same disk ``` **3. A manual `mv` between the two container paths succeeds without error:** ``` $ docker exec Databasus sh -c "touch /databasus-data/temp/testfile && mv /databasus-data/temp/testfile /databasus-data/backups/testfile" # No output, no error — file arrived successfully in /databasus-data/backups/ ``` **4. Active mounts as reported by `docker inspect`:** ```json { "Source": "/mnt/user/Backups/Terra/databasus-bkp", "Destination": "/databasus-data/backups" }, { "Source": "/mnt/user/Backups/Terra/databasus-temp", "Destination": "/databasus-data/temp" }, { "Source": "/mnt/user/appdata/databasus/data", "Destination": "/databasus-data" } ``` ### Conclusion Since a manual `mv` (which uses the same `rename` syscall) works fine between the two paths inside the container, the issue appears to be specific to how Databasus internally performs the rename operation — possibly using a lower-level approach that does not behave the same way under Unraid's `shfs` (a FUSE-based virtual filesystem that merges multiple physical disks) when volumes are split across separate bind mounts. ### Request Could you investigate how the temp-to-backups file move is implemented internally? A fallback using a copy-then-delete approach instead of a direct `rename` syscall would resolve the issue in environments where `rename` across bind mounts fails despite the paths appearing to be on the same filesystem. Happy to provide any additional information or run further tests if needed.
MrUnknownDE added the bugbugbugbugbugbugbugbugbugbugbugbugbugbug labels 2026-04-05 16:15:41 +02:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github/databasus#68