mount: Ensure a hard link count > 0 for all files#21784
Conversation
When using `restic mount` to serve a repository via a POSIX host's file system, all files backed up from Windows systems will show up on the mounting host with a (hard)link count of 0. While this is not a problem in general and most programs do not even register this strange value, some others (such as Samba's smbd(8)) will go the extra mile and check a file's stat() results for various properties (such as a positive non-zero link count), and refuse to operate if any of the reported values appear off. Since other inode properties absent from non-POSIX backup sources are also "faked up" (e.g., the inode number) during mount and work fine in general, the chances of this change to be in any way harmful are probably rather slim.
|
I was asked on IRC to elaborate on the setup that made me find this problem, so here goes. Below is restic 0.18.1 having mounted a repository at The crucial part is the Links: 0 data right after the (faked up, since Windows does not have those) Inode: number. When sharing the contents of With the patch from this PR applied on top of current master and using it to mount the repo, the result from This change alone fixes smbd's odd behavior (and potentially other software) that cannot or is unwilling to deal with a link count of 0. Since a link count of 0 would normally indicate a deleted file (which probably should not be observable on a POSIX system outside of Linux' |
MichaelEischer
left a comment
There was a problem hiding this comment.
LGTM. Thanks a lot for finding this. After reading through the PR description twice, I'm very sure that this is finally the fix for #2034 and #4382 .
I've added a basic test (AI coded) to prevent regressing this in the future and a short changelog entry that explains this without going too much into technical details although that's surprisingly tricky here. Please take a look.
clrossel
left a comment
There was a problem hiding this comment.
I would prefer updating the comment in internal/fuse/file.go as noted.
a7d36d6 to
4547fd7
Compare
|
Changes (including the test) look great - I'd be very happy if this fix were merged this way :) |
When using
restic mountto serve a repository via a POSIX host's file system, all files backed up from Windows systems will show up on the mounting host with a (hard)link count of 0.While this is not a problem in general and most programs do not even register this strange value, some others (such as Samba's smbd(8)) will go the extra mile and check a file's stat() results for various properties (such as a positive non-zero link count), and refuse to operate if any of the reported values appear off.
Since other inode properties absent from non-POSIX backup sources are also "faked up" (e.g., the inode number) during mount and work fine in general, the chances of this change to be in any way harmful are probably rather slim.
What does this PR change? What problem does it solve?
This makes it possible to serve up a
restic mount-provided repository via the Samba project'ssmbd. Without it, accessing a regular file backed up from a Windows source host will cause the smb client to croak with the NT status equivalent of ENOENT.To work around this with this patch, the fuse layer will ensure a minimal link count of 1 for all files it presents to the mounting host.
Was the change previously discussed in an issue or on the forum?
No, merely on IRC.
Checklist
changelog/unreleased/that describes the changes for our users (see template).