Bug 5669 - Problems with soft-/hardlimit-quota on Windows XP-clients
Summary: Problems with soft-/hardlimit-quota on Windows XP-clients
Status: RESOLVED WORKSFORME
Alias: None
Product: Samba 3.6
Classification: Unclassified
Component: File services (show other bugs)
Version: 3.6.5
Hardware: x86 Linux
: P3 normal
Target Milestone: ---
Assignee: Björn Jacke
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-08-04 17:25 UTC by Thorsten Edler
Modified: 2012-10-24 16:12 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thorsten Edler 2008-08-04 17:25:17 UTC
Since 2003 we compiled several samba-versions. In every version we used to update, there was the same problem, using samba's hard-/softlimit-quota: If you reach with a WindowsXP-client a definated quota softlimit of a samba-share, it behaves just like a hardlimit (under windows). So, every following access is blocked! But isn't the sense of a softlimit, that there's a little bit more range up to an existing hardlimit? So, whatever, our proposal to fix this problem, is the following patch, that we are now using since 2003 (in every updated samba-version) and it worked very fine. Perhaps, it will be possible to implement this regularly? :-)

************************** snip *******************************************

*** source/smbd/quotas.c        Sun Jul 13 01:57:56 2003
--- source/smbd/quotas.c.orig   Sun Jul 13 01:59:43 2003
@@ -227,7 +227,8 @@
        }

        /* Use softlimit to determine disk space, except when it has been exceeded */
-       if (
+       // Kick it! :)
+       /*      if (
                (D.softlimit && D.curblocks >= D.softlimit) ||
                (D.hardlimit && D.curblocks >= D.hardlimit) ||
                (D.isoftlimit && D.curinodes >= D.isoftlimit) ||
@@ -237,12 +238,14 @@
                *dsize = D.curblocks;
        } else if (D.softlimit==0 && D.hardlimit==0) {
                return(False);
-       } else {
-               if (D.softlimit == 0)
-                       D.softlimit = D.hardlimit;
+       } else { */
+               // Setting softlimit to hardlimit,
+               // so windows uses/accepts the real hardlimit 
+               // if (D.softlimit == 0)
+               D.softlimit = D.hardlimit;
                *dfree = D.softlimit - D.curblocks;
                *dsize = D.softlimit;
-       }
+       // }

        return (True);
 }

/* Credits for this simple patch to: Gregor Lawatscheck, Berlin (Germany), www.mpexnet.de */

************************** snip *******************************************

Best regards,
/Thorsten Edler, 
Berlin (Germany)
Comment 1 Dewi Griffiths 2009-02-24 19:34:57 UTC
This is a pretty critical bug in my opinion, it really messed us up at our site and should be fixed as soon as possible for mainstream release. Granted it's a bug in the way WindowsXP accept stuff too, but surely this is a fairly major issue for anyone trying to really implement quotas on users.
Comment 2 Thorsten Edler 2009-12-30 19:18:03 UTC
We've tested this. It's fixed now in 3.4.3 (possibly earlier version)!
Many thanks!
Comment 3 Tsukasa HAMANO 2012-05-07 03:20:31 UTC
this fix was not applied to mainstream yet.
Comment 4 Guenther Deschner 2012-05-10 07:20:20 UTC
apparently still a problem, reopening.
Comment 5 Björn Jacke 2012-09-06 05:48:49 UTC
it's not as simple as that. Windows does not know the concept of grace time. So if we tell the client that he has $hardlimit space then he will be surprised when he cannot write anymore $gracetime days after he crosses the $softlimit barrier.

Windows only knows the concept of a quota warning level, which is similar but in the end completely different from teh softlimit/gracetime concept. I would recommend to set the soft and the hard limit to the same value to not let the windows user run into trouble that arise when they get cross the softlimit and run out of gracetime.