You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note that the leading d indicates both Dir1 and Dir2 are (real) directories, however their parent /mnt/raid/shares/Public and grandparent /mnt/raid/shares are both btrfs subvolumes. The root of the btrfs filesystem is mounted at /mnt/raid.
# btrfs subvolume list /mnt/raid
ID 32501 gen 3395407 top level 5 path shares
ID 52405 gen 3483274 top level 32501 path shares/Public
On Windows/macOS client after mounting the share over SMB3, Dir2 somehow becomes a file, e.g. on macOS
% ls -lh /Volumes/Public
drwx------ 1 test staff 16K Jul 22 01:21 Dir1
-rwx------ 1 test staff 0B Jan 30 2022 Dir2
Note the missing leading d for Dir2. Additionally on macOS, attempting to list /Volumes/root/mnt/raid causes Terminal.app to stuck and Finder.app to beachball (application not responding).
None of the above happens with Samba server.
Environment
Server: tested on Debian 12 and Alpine 3.18
Client: tested on Windows 10 and macOS 13.5
Related
#556 looks related and also involves btrfs subvolumes, but its symptom is different from this one.
The difficult part is that I'm unable to reliably reproduce the behavior. The directory-shown-as-file symptom seems a result of interaction between btrfs subvolumes with snapshots and ksmbd (recall that samba does not have this problem), but I cannot just create new directories to reproduce the symptom (though existing problematic directories can reliably be shown as files on clients). It might have something to do with non-unique inode numbers as the article (https://lwn.net/Articles/866582/) suggests, or it might be some other problems.
I was hoping you could provide me some directions or tools to further investigate, as the issue seems pretty intricate to trigger.
Symptom
Some (not all) directories in
btrfs
subvolumes onksmbd
servers appear as files when mounted over SMB on Windows and macOS clients.On
ksmbd
server# ls -lh /mnt/raid/shares/Public drwxr-sr-x 1 smbuser smbuser 1.3K Jul 22 01:21 Dir1 drwxr-sr-x 1 smbuser smbuser 1.1K Jan 30 2022 Dir2
Note that the leading
d
indicates bothDir1
andDir2
are (real) directories, however their parent/mnt/raid/shares/Public
and grandparent/mnt/raid/shares
are bothbtrfs
subvolumes. The root of thebtrfs
filesystem is mounted at/mnt/raid
.# btrfs subvolume list /mnt/raid ID 32501 gen 3395407 top level 5 path shares ID 52405 gen 3483274 top level 32501 path shares/Public
On Windows/macOS client after mounting the share over SMB3,
Dir2
somehow becomes a file, e.g. on macOSNote the missing leading
d
forDir2
. Additionally on macOS, attempting to list/Volumes/root/mnt/raid
causes Terminal.app to stuck and Finder.app to beachball (application not responding).None of the above happens with Samba server.
Environment
Related
#556 looks related and also involves
btrfs
subvolumes, but its symptom is different from this one.https://lwn.net/Articles/866582/ might give some clues but I don't really understand the underlying mechanisms.
Please let me know how I could further investigate and provide additional information to pinpoint the root cause.
Thanks very much!
The text was updated successfully, but these errors were encountered: