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?
*** Bug 5875 has been marked as a duplicate of this bug. ***
Created attachment 6189 [details] Samba 3.5.6 disk quota patch
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.
Jeremy?
I'll take a good look at this monday. Sorry, still cold+flu :-(. Jeremy.
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: http://wiki.samba.org/index.php/UNIX_Extensions#SMB_QUERY_POSIX_FS_INFO as: 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 ? Jeremy.
This sounds somewhat similar to this bug reported against RHEL a while back: https://bugzilla.redhat.com/show_bug.cgi?id=499397 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?
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") ? Jeremy.
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.
According to the RH bug I referenced in comment #7, windows uses 2 infolevels of interest here: #define SMB_QUERY_FS_SIZE_INFO 0x103 #define SMB_QUERY_FS_FULL_SIZE_INFO 0x3ef 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. :)
(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.
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. Jeremy.
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.
(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 http://msdn.microsoft.com/en-us/library/windows/desktop/aa364935%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/ee442049%28v=prot.10%29 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?
(In reply to Björn Jacke from comment #14) closing as worksforme now according to my last comment.