samba mount fails to write

Bug #1735953 reported by NBR
This bug affects 3 people
Affects Status Importance Assigned to Milestone
samba (Ubuntu)

Bug Description

Ubuntu 17.10 appears to aggressively trigger Samba bug 10541 ( ). Previous versions of Ubuntu worked fine, but 17.10 appears to request quota information on every write, resulting in a complete inability to write to files.

Remote Samba share is mounted as cifs as read-write, and has been working for years and many software releases. Unable to write/create files from bash, from GUI file browser, or even from a Windows VM with access to the mounted location. I haven't seen any scenario where Ubuntu 17.10 can write to the share.

Server is running Samba 4.7.3 with a long-running good configuration.

Every write request from my Ubuntu desktop results in the following server log:

[2017/12/02 16:44:25.306674, 0] ../source3/lib/sysquotas.c:461(sys_get_quota)
  sys_path_to_bdev() failed for path [.]!

There are no other log entries.

The root bug appears to be in Samba, but recent changes to Ubuntu have triggered the bug in a way that breaks write functionality.

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

tags: added: bot-comment
Paul White (paulw2u)
affects: ubuntu → samba (Ubuntu)
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Are you using btrfs, zfs and/or xfs on the server where the exported share is?

Revision history for this message
NBR (nbr17) wrote :

Yes, it's on a btrfs partition in line with the samba bug.

Revision history for this message
NBR (nbr17) wrote :

I was mistaken about the cause of this bug. It appears that some default setting has changed, and cifs mounts need uid and gid options passed explicitly. In previous Ubuntu versions, I could mount cifs with just credentials provided I set the owners of the mount point and remote files correctly, a one-time detail. In Ubuntu 17.10, if I fail to pass uid,gid to cifs mount options, it's mounted as root:root and the only access is by everyone permissions or if I'm root.

Workaround: when mounting cifs, use options as such: defaults,uid=1001,gid=1001,credentials=[path]

Where the ids can be retrieved using 'id [name]' from the shell.

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

When you use the uid/gid options, do all files in the share get owned by that uid/gid?

Can you check the output of the mount command after mounting the share, with and without uid/gid, and see which options ended up being used? That output will include defaults that you did not specify.

For example, here when I mount from a ds216 synology NAS using these options in fstab "username=andreas,vers=3.0,noauto" I get this in the output of mount:

uid and gid were added automatically in my case. My fstab line is:
//server/downloads /ds216/downloads cifs user,username=andreas,vers=3.0,noauto

This is on artful. cifs-utils 2:6.7-1

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Oh, and I meant to add that this NAS is using btrfs

Changed in samba (Ubuntu):
status: New → Incomplete
Revision history for this message
Punkadiddle (punkadiddle) wrote :

Same bug on 18.04 samba + btrfs.

Revision history for this message
Punkadiddle (punkadiddle) wrote :

There's a hacky workaround to disable quotas that makes the error vanish from the logs. Not sure of sideeffects.

Put a line like this into your smb.conf [global] to point it to the attached script
 get quota command = /opt/bin/

The script will then tell samba on each request, that quotas are disabled. The way they didn't even quote the parameters suggests, that the option is not well tested.

Revision history for this message
Tolga Cakir (tolga9009) wrote :

The "sys_path_to_bdev() failed for path [.]!" error has already been posted upstream 5 years ago (, yet this error still shows up. It doesn't do harm in my setup, but it's annoying and clutters the logs. I've done some Google-Fu on this matter and I think I've found the root cause and an easy workaround.

The culprit seems to be within sys_path_to_bdev(): getmntent(). Issue is, if you have a nested BTRFS subvolume as a Samba share, which gets auto-mounted by its parents, there is no fstab entry for this subvolume, but getmntent() looks in fstab for mount points.

Lets say your fstab contains / and /srv as mount points, but you have created a BTRFS subvolume for your share /srv/samba/share. getmntent() tries to find /srv/samba/share in fstab, but fails, thus leading to that error message. Sidenote: there are good reasons to use BTRFS subvolumes for shares e.g. snapper support via "vfs object = snapper", which **requires** the share to be a BTRFS subvolume.

Knowing the root cause, the workaround is pretty simple: add the BTRFS subvolume you're using for Samba to /etc/fstab.

Also: if your Samba share is not a BTRFS subvolume itself, but it's located under an auto-mounted BTRFS subvolume, will still require you to add that subvolue to /etc/fstab. E.g. /srv is in /etc/fstab, /srv/samba is a BTRFS subvolume and your share is a usual folder /srv/samba/share, you will need to add /srv/samba to /etc/fstab.

I've successfully tried this workaround on samba 4.10.10-2, kernel, btrfs-progs 5.3.1-3 on Arch Linux. Should also work on Ubuntu.

Hope this helps someone.


To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.