mirror of
https://github.com/databasus/databasus.git
synced 2026-04-06 00:32:03 +02:00
invalid cross-device link when using split Docker volume mapping on Unraid
#68
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Gekko23 on 3/13/2026
Bug Report:
invalid cross-device linkwhen using split Docker volume mapping on UnraidEnvironment
Setup / Volume Mapping
To separate backup files from appdata, the following split volume mapping was configured:
/mnt/user/appdata/databasus/data/databasus-data/mnt/user/Backups/Terra/databasus-bkp/databasus-data/backups/mnt/user/Backups/Terra/databasus-temp/databasus-data/tempProblem
Every backup attempt fails with the following error:
Investigation
Extensive debugging was done to rule out filesystem-level causes:
1. Both paths report the same filesystem inside the container:
2. Both host paths resolve to the same physical disk:
3. A manual
mvbetween the two container paths succeeds without error:4. Active mounts as reported by
docker inspect:Conclusion
Since a manual
mv(which uses the samerenamesyscall) 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'sshfs(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
renamesyscall would resolve the issue in environments whererenameacross 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.