Bug 10541 - sys_path_to_bdev fails for btrfs subvolumes
sys_path_to_bdev fails for btrfs subvolumes
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services
All All
: P5 normal
: ---
Assigned To: David Disseldorp
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2014-04-05 12:32 UTC by Andreas Noever
Modified: 2019-09-12 01:02 UTC (History)
4 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Noever 2014-04-05 12:32:46 UTC
smbd prints

[2014/04/05 13:25:20.282135,  0] ../source3/lib/sysquotas.c:406(sys_get_quota)
sys_path_to_bdev() failed for path [.]!

whenever a path from a btrfs subvolume is accessed (for example when typing ls in smbclient).

I did some debugging and the reason is that btrfs has per subvolume st_dev values, but only the main volume appears in getmntent(). The loop in sys_path_to_bdev thus fails to find the mount path.


I have only one mounted partition
/dev/sda3 on / type btrfs (rw,relatime,space_cache)

/mnt is a folder and /mnt/data, /mnt/data/share are subvolumes:
stat /
Device: 12h/18d	Inode: 256
stat /mnt
Device: 12h/18d	Inode: 2512
stat /mnt/data
Device: 26h/38d	Inode: 256
stat /mnt/data/share
Device: 2dh/45d	Inode: 256
Comment 1 David Disseldorp 2014-11-05 11:37:06 UTC
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.
Comment 2 Björn Jacke 2014-11-06 11:02:34 UTC
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.
Comment 3 Alessandro Bruni 2014-12-21 12:35:03 UTC
Hi all, are there updates on this bug? I hit the problem on my configuration, and I'd like to help if needed.
Comment 4 Björn Jacke 2015-12-04 08:53:24 UTC
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.
Comment 5 Raul 2016-06-12 15:44:39 UTC
This happens with a zfs filesystem as well.
Comment 6 Chris Smith 2017-08-07 12:48:43 UTC
Fairly old bug, still hitting this with 4.6.5 - and with the vfs_btrfs module.
Comment 7 Björn Jacke 2017-12-06 09:01:31 UTC
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.
Comment 8 hendrik@friedels.name 2019-05-21 19:52:07 UTC

I'd like to refer to this discussion:

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.