Subsequent backups do not get created at all, backing up process just goes on for ever. Thats been the case on both fedora 43 and Ubuntu 25.10 fresh installs. No error comes up.
However, as a test, I just tried exporting the backup location as an nfs share and deja dup worked absolutely fine. Created the backup, then browsed the contents instantly. I hadn’t even automounted it in my desktop. So the issue is specifically with smb share into unraid. Any idea what could be causing this?
Hello! There are two issues I’m tracking with network server locations and restic:
- One is an issue that ended up being quite lowlevel, needing to be fixed in fuse and Go themselves. The fuse release with a fix is out, Golang should be early next month. I’m waiting on that and then a restic release built with the new Golang, before I cut a 49.3 release. This doesn’t affect older fuse releases, so it’s likely only an issue on more up to date distros.
- Another is an issue with restic not handling some filesystems that don’t support
chmod, which usually happens with fuse-mounted systems like smb. This was a regression introduced in 0.18.0 - maybe I should downgrade the flatpak version of restic until we have 0.18.2… hmm
I’m guessing you’re hitting the second issue? But maybe the first is also raising its head. For now, unless this is critical, I’d say wait a week or so until I can hopefully cut a new 49.3 release, with a newly released restic 0.18.2.
I released s flatpak update downgrading Restic to 0.17.3 until they release a new update. That might help if you were only hitting the second issue.
If you are also hitting the first, the only fix for now is to use an older or newer distro that has a fuse version without the issue.
There’s an another (annoying maybe) workaround - set up an rclone remote and set that as your storage location pointing at the remote location.
Appreciate it! Another workaround is to export the network share as nfs. The issue only happened when accessing as smb. I will try smb tomorrow and let you know.