Thanks for the report Andreas, I've hit this one too.

Btrfs quotas are applied at a subvolume level and can restrict total, unshared or compressed data usage. Handling of this filesystem specific behaviour may be better suited for the vfs_btrfs module. I need to take a closer look.

there is a similar problem for XFS. XFS also has the concept of directory based quotas (project quota). I think the concept of directory based quota is hard to get in line with SMB quotas, which have no clue of directory based quotas AFAIK. In any case I think if we can find a good solution in Samba it should be generic and not in vfs_btrfs only.

Hi all, are there updates on this bug? I hit the problem on my configuration, and I'd like to help if needed.

Dave, did you make any progress here? Any idea how to solve that?

Afaik Windows allows setting quota on junction points. Mapping subvolumes to junction points might be a way to cleanly map the subvolume quota problem to the windows world. Though, I think our support for junction points generally needs to be improved for that.

This happens with a zfs filesystem as well.

Fairly old bug, still hitting this with 4.6.5 - and with the vfs_btrfs module.

an anon user asked me to add the following comment (unverified by myself):

This bug appears to block all SMB writes in Ubuntu 17.10. I have samba 4.7.3 installed on an Arch file server. The system has worked well for years, but after upgrading the client machine from Ubuntu 17.04 to 17.10, I'm unable to write to SMB shares at all. The shares are mounted as read-write, the configuration is unchanged. I'm unable to write from bash shell, GUI programs, or even a Windows VM with access to the directory. l client machine still on 17.04 continues to work fine.

The server emits only this log message, once per write attempt:

[2017/12/02 16:44:25.306674, 0] ../source3/ib/sysquotas.c:461(sys_get_quota)

  sys_path_to_bdev() failed for path [.]!
The share points to a btrfs filesystem on the server. Whereas this bug may have previously been harmless, it now appears that samba is incompatible with btrfs and several other filesystems for anyone using an updated client.

I've also added an Ubuntu bug (1735953 - https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1735953).

You can also add that defining "HAVE_SYS_QUOTAS 0" and rebuilding the server software seems to work as a temporary hack, for any other users with the same problem.

Hello,

I'd like to refer to this discussion:
https://www.spinics.net/lists/samba/msg157076.html

It was implied that the fact that this bug is five years old without many users complaining implies that it has low impact.

To me, this interpretation is not neccessarily right. I saw, that this bug is assigned and did not see the need to 'annoy' developers by asking about the status here. Furthermore, commenting requires an account.

But if it helps...

Capturing the status of the discussion:

----------
That's because the concept of a btrfs "subvolume" completely
breaks the POSIX idioms that smbd depends on.
 
We absolutely identify a file by a dev/ino pair, and
expect the dev to remain consistent under an exported
share path.
 
If you sub-mount this also breaks smbd dfree/quotas, and
that's a lot more common.
 
This identity is baked into Samba in order to implement
leases/oplocks and it's not going to change.
 
If you want to do this (subvolumes/submounts) I think
you should get familiar with the:
 
dfree command:
 
set quota command:
 
set quota command:
 
scripts in smb.conf.
------------

Regards,
Hendrik

Hi,

I've experienced the same error message using Arch Linux kernel 5.3.11.1-1, samba 4.10.10-2 and btrfs-progs 5.3.1-3. There were no functional issues; I could read/write with my clients (Arch Linux laptop w/ GNOME3 + gvfs-smb, Windows 10 w/ SMB3), but log cluttering annoyed me, as hundreds of lines of the same error message were generated during normal operation (e.g. browsing directories).

# smb.conf
[global]
bind interfaces only = Yes
dns proxy = No
interfaces = 192.168.1.0/24
logging = systemd
max log size = 50
server min protocol = SMB3
server role = standalone server
server string = Ragnarok Samba Server
idmap config * : backend = tdb
hosts allow = 192.168.1. 127.

[Archive]
create mask = 0644
hide unreadable = Yes
path = /srv/samba/Archive
read only = No
valid users = tolga

BTRFS top level subvolumes were @, @srv and @home, mounted under /, /srv and /home using seperate entries in /etc/fstab. In order to use snapper, I created a BTRFS subvolume for my share under /srv/samba/Archive. BTRFS auto-mounts nested subvolumes, so there was no /etc/fstab entry for /srv/samba/Archive.

And that's the crucial point. sys_path_to_bdev() fails, because getmntent() expects an entry in /etc/fstab. From getmntent(3) man page:
"These routines are used to access the filesystem description file /etc/fstab and the mounted filesystem description file /etc/mtab."

There related issue has been discussed here: https://savannah.gnu.org/bugs/?50859

The workaround is pretty simple: add the BTRFS subvolume you're using as a share to /etc/fstab. If your share is not a BTRFS subvolume, but your share directory is located beneath an auto-mounted BTRFS subvolume (not listed in /etc/fstab), add that subvolume to /etc/fstab and the error will go away. No hacky scripts involved.

The "actual fix" for this problem is a bit more challenging. Not technically, but politically. Should this be fixed in GNU, in BTRFS and/or in Samba? One idea to fix this in samba would be something like this:
getmntent() failed? -> do we have a BTRFS / ZFS filesystem? -> if yes -> report path of BTRFS subvolume and continue as if getmntent() succeeded; fail otherwise.

There are probably better, cleaner and simpler ways to fix it, especially in the other projects, but that's just an idea.

In the meantime, the workaround works.

Cheers,
Tolga