Bug 5395 - Unix Extensions + ext3 quotas + df
Summary: Unix Extensions + ext3 quotas + df
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.9.4
Hardware: All All
: P3 major (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
: 5875 (view as bug list)
Depends on:
Blocks: 9281
  Show dependency treegraph
Reported: 2008-04-15 04:20 UTC by Juanjo Villaplana
Modified: 2021-06-28 11:58 UTC (History)
7 users (show)

See Also:

Samba 3.5.6 disk quota patch (2.36 KB, patch)
2011-01-07 21:24 UTC, Ryan G (mail address dead)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Juanjo Villaplana 2008-04-15 04:20:17 UTC
We are using CIFS to mount user's home directories in our desktops. Unix Extensions are needed in order to start Gnome/KDE sessions over a CIFS fs.

Desktop systems are running Centos 5.1 (kernel 2.6.18-53.1.14.el5 ---CIFS Version 1.48aRH---) and home dirs are mounted with these options: noacl,serverino,iocharset=iso8859-1

The server is running RHEL 4.5 (samba-3.0.25b-1.el4_6.4), with userquota enabled.

We used que quota/disk free mapping, and directed the users to run "df -h ~" instead of "quota" in order to check his quota status, but this stopped working since we upgraded from samba-3.0.10-1.4E.12.2 to samba-3.0.25b-1.el4_6.4.

Looking at the source code it seems that samba-3.0.10 services a "df -h" via SMB_QUERY_FS_SIZE_INFO, but samba-3.0.25b services this request via SMB_QUERY_POSIX_FS_INFO if Unix Extensions are enabled or via SMB_QUERY_FS_SIZE_INFO if Unix Extensions are disabled.

SMB_QUERY_FS_SIZE_INFO uses the quota/disk free mapping but SMB_QUERY_POSIX_FS_INFO doesn't (is mapped to statvfs) . We can't disable Unix Extensions, so the mapping is lost and we can't find a way to query disk quotas (via CIFS) from out desktops.

Is there a way to keep Unix Extensions enabled and preserve the quota/disk free mapping with latest samba 3.0.x?
Comment 1 Karolin Seeger 2009-05-13 03:37:36 UTC
*** Bug 5875 has been marked as a duplicate of this bug. ***
Comment 2 Ryan G (mail address dead) 2011-01-07 21:24:58 UTC
Created attachment 6189 [details]
Samba 3.5.6 disk quota patch
Comment 3 Ryan G (mail address dead) 2011-01-07 21:32:45 UTC
The patch attached above is based off of the patch here: http://lists-archives.org/samba/46198-unix-extensions-ext3-quotas-df.html

It fixes dfree reporting when dfree command is set in smb.conf and unix extensions are enabled. It would be great to see this be fixed upstream.
Comment 4 Volker Lendecke 2011-01-08 03:07:00 UTC
Comment 5 Jeremy Allison 2011-01-08 22:18:54 UTC
I'll take a good look at this monday. Sorry, still cold+flu :-(.

Comment 6 Jeremy Allison 2011-01-10 18:55:18 UTC
Steve, can you look at this please ? The underlying bug is that the POSIX CIFS call SMB_QUERY_POSIX_FS_INFO doesn't define how it interacts with an underlying quota system.

The return is defined here:



size 	Offset 	Field Description
4 	0 	Optimal Transfer Size (bsize on some operating systems)
4 	4 	Blocksize
8 	8 	Total Blocks
8 	16 	Blocks Available
8 	24 	User Blocks Available
8 	32 	Total File Nodes
8 	40 	Free File Nodes
8 	48 	File System Identifier (fsid) 

Should we change the "Total Blocks", "Blocks Available", "User Blocks Available" to match the current user quota ?

Comment 7 Jeff Layton 2011-01-10 19:47:18 UTC
This sounds somewhat similar to this bug reported against RHEL a while back:


I don't think that statfs() calls ought to report anything relating to the quota. That info seems better suited to the kernel quota interfaces. Perhaps we should consider a new infolevel for this?
Comment 8 Jeremy Allison 2011-01-10 19:56:46 UTC
Well we already have SMB_QUERY_FS_SIZE_INFO, which does the quota modification for the requesting user. So does this mean it's a client bug ? Or is the original reporter just incorrect in that "df" must always return non-quota sizes, and users must use the "quota" command to get their current quota (which would make this "Not a bug") ?

Comment 9 Ryan G (mail address dead) 2011-01-10 20:14:25 UTC
The quota disk free is reported according to the quota with unix extensions off so at the very least the current behavior is inconsistent. Also with unix extensions on, the dfree command config directive is completely ignored.

If this isn't a bug I should at least be able to work around it with a custom dfree script, but I can't even do that right now with the config directive being ignored.
Comment 10 Jeff Layton 2011-01-11 06:57:11 UTC
According to the RH bug I referenced in comment #7, windows uses 2 infolevels of interest here:

#define SMB_QUERY_FS_SIZE_INFO      0x103

If the info in that bug is correct (and I have not verified it), then the info returned in SMB_QUERY_FS_SIZE_INFO does not reflect quota sizes, but the "actual" size of the fs. The second one has fields that give information about the quota.

So it seems that if samba is returning "quotaed" sizes in SMB_QUERY_FS_SIZE_INFO responses then it's doing it wrong.

I'm not sure that POSIX has anything to say about quotas and statfs() calls, but most filesystems don't skew those values according to the quota of the calling user.

I think the upshot here is this:

SMB_QUERY_FS_SIZE_INFO should not be affected by the user's quota

SMB_QUERY_FS_FULL_SIZE_INFO should show the value of the quota in the CallerAvailableAllocationUnits field

In the SMB_QUERY_POSIX_FS_INFO response it's probably reasonable to have the "User Blocks Available" reflect the quota, and leave "Total Blocks" and "Blocks Available" reporting the actual size of the fs.

...but that's just my opinion. :)

Comment 11 Jeff Layton 2011-01-11 07:11:44 UTC
(In reply to comment #10)

> In the SMB_QUERY_POSIX_FS_INFO response it's probably reasonable to have the
> "User Blocks Available" reflect the quota, and leave "Total Blocks" and
> "Blocks Available" reporting the actual size of the fs.

OTOH, perhaps it would be better not to have that reflect the quota so that we can make a statfs() call on the client basically equivalent to a statfs() call on the server.

And maybe just use the FILE_GET_QUOTA_INFORMATION infolevel fetch quota info.
Comment 12 Jeremy Allison 2011-01-11 14:41:51 UTC
Ok, I've looks closely at the infolevels and the problem is we're mixing up user quota info with disk free info in the disk_free() function call. We have a separate VFS call get_quota(), but we're not using it to provide the user-specific values returned in SMB_QUERY_FS_SIZE_INFO or SMB_QUERY_FS_FULL_SIZE_INFO.

In fact it's a separate interface, currently only used by the nttrans quota code, and is different (although arguably superior to) the old quota code used in smbd/quotas.c, means we have a bit of a mess.

The correct thing to do (for 3.6.x) is to remove the smbd/quotas.c code and remove the quota calling code from disk_free(). The trans2 and nttrans info levels should call directly into the "disk_free()" call for the disk information, and additionally call into the VFS call get_quota() and select the right information from both for the info level returns.

SMB_QUERY_POSIX_FS_INFO should be left alone as a "raw" statvfs call IMHO.

I'll look at making these changes for 3.6.x, but this will be a longer fix than the simple one here.


Comment 13 Björn Jacke 2012-09-06 12:48:33 UTC
okay, we have now almost eliminated quota.c. Just Solaris quita code is left there. The proposed change to not mess with dfree/quota would be possible then.
Comment 14 Björn Jacke 2012-09-11 10:01:02 UTC
(In reply to comment #12)
> The correct thing to do (for 3.6.x) is to remove the smbd/quotas.c code and
> remove the quota calling code from disk_free().

actually this is exactly what Windows does, see


Also cross checked that by sniffing a client. Maybe there is a fsctl or so which gets us the 

Any other good idea how to move on with the statvfs() mapping thing and interaction with user quota?
Comment 15 Björn Jacke 2021-06-28 11:58:53 UTC
(In reply to Björn Jacke from comment #14)
closing as worksforme now according to my last comment.