Symlink in share path hinders total and free disk space reporting to Windows [updated]

[romanrm]

Hello,

In Debian with
ksmbd-tools 3.4.5-1~bpo11+1
kernel 6.1.0-3-armmp-lpae

Mapping a network drive in Windows and opening the drive properties, the total and available disk space are both shown as 0 bytes: https://romanrm.net/2023-02-21T221301Z-ksmbd.png

Meanwhile "ksmbd.mountd -n" prints on the console:

[ksmbd-worker/22585]: ERROR: Unsupported share info level (write): 2
[ksmbd-worker/22585]: ERROR: Unsupported share info level (read): 2

Lacking support for reporting free disk space really limits the usability of ksmbd. For instance such a share is not suitable as a destination for Windows built-in backup. And I cannot even verify if there is a performance improvement compared to Samba, because CrystalDiskMark refuses to operate on the ksmbd share, citing not enough free disk space. So I hope you could consider adding this feature.

Thanks!

[namjaejeon]

Hello Roman,

Sorry, There is no issue on my test. Could you please share your test environment ?

1. Windows client version.
2. Local filesystem of share directory.
3. SMB1 or SMB2/3 ?
4. If possible, provide wireshark(or tcpdump) to me.

thanks.

[romanrm]

Hello,

Thank you for the quick response. It appears the issue is only observed when the share is inside a Btrfs subvolume (updated below)

This is my initial tested shared directory:

# df -h /backup/win/alpha/winbkp/
Filesystem      Size  Used Avail Use% Mounted on
-               469G  323G  143G  70% /mnt/p3/backup

Here /backup is a symlink to /mnt/p3/backup, which is a subvolume on Btrfs. This results in the described issue. However creating a simple folder on the same Btrfs filesystem:

# df -h /mnt/p3/test/
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda3       469G  323G  143G  70% /mnt/p3

and exporting that as a share, works fine and provides the free space reporting to Windows.

As you can see in the above case even "df" cannot report the actual filesystem of the subvolume directory. So I suspect there is a similar caveat in ksmbd.

Thanks!

[namjaejeon]

Hm.. I can not understand fully. After all, you are suspecting symlink has problem ? Note that ksmbd doesn't support symlink.

[namjaejeon]

As you can see in the above case even "df" cannot report the actual filesystem of the subvolume directory.

What is difference between before & after ? /dev/sda3?

[romanrm]

Actually yes, Btrfs subvolume is not to blame, the issue is the symlink. I removed my previous incorrect reply.

If "path = " of a share in the config file points to a symlink, or symlink is present somewhere within this path, then the disk space reporting does not work. But the file content of the share is visible from the Windows client just fine, which is why it was at first confusing and I didn't think it was a path issue.

[namjaejeon]

Okay, thanks for your check:) I guess that ksmbd doesn't support symlink in file open. but windows disk space seems to open share directory file to get disk space from ksmbd. I will confirm it after checking more. In worst case, you may have not to use symlink share directory when using ksmbd. let me check..

[namjaejeon]

When I testing symlink share, windows client can not access network drive. And show 0 disk space as you report.

drwxrwxrwx 2 linkinjeon linkinjeon 4096 2월 6 21:54 1
lrwxrwxrwx 1 root root 1 2월 22 22:31 symlink -> 1

[homes]
comment = contents share
path = /mnt/symlink
read only = no

As I told you, ksmbd doesn't support symlink file. For now, you should not use symlink share when using ksmbd.
And I am planning symlink support in ksmbd, I need to work more high priority jobs. Symlink support is not absolutely necessary, is it?

[romanrm]

It might not be, but the lack of symlink support certainly prevents me from rolling it out on my main file server. For now I can only try it out in a limited scope on a backup destination server.

But I think here is a rather different and simpler issue: this is not about handling of symlinks in general within the share content itself, but about just figuring out once where the base share directory is. Same as doing:

$ realpath /mnt/symlink
/mnt/1

And then just proceed with using /mnt/1 as if this was set in "path =".

It feels like this part could be fixed up very easily and should not be related to whether "follow symlinks" or the like is supported or on/off.

[namjaejeon]

OK.