Solved Samba: quota errors logged

Hi,

Since I upgraded to 12.0-RELEASE, I see in dmesg -a this kind of errors each time I copy a new file in my share:
... smbd[1055]: [2018/12/18 18:46:11.633619, 0] ../source3/lib/sysquotas_4B.c:148(sys_quotactl_4B)
... smbd[1055]: failed to get quota for user ID 65534 on .: No such file or directory
... smbd[1055]: [2018/12/18 18:46:11.650784, 0] ../source3/lib/sysquotas_4B.c:148(sys_quotactl_4B)
... smbd[1055]: failed to get quota for group ID 65534 on .: No such file or directory

These errors don't appear with FreeBSD 11.2. I use Samba 4.6 but I saw the same with the 4.7 version (all installed with pkg).
The user ID 65534 is "nobody" but my analysis stops there.

My smb4.conf is very basic and no quota is involved.
[global]
workgroup = Mygroup
security = user
map to guest = Bad User

[smb-test]
path = /smb-test
read only = no
public = yes

Any idea?
 
Not sure to well understand "from source".

Concerning the base system, including the kernel, I used the commands given in the hanbook. My kernel was generic, so is the 12.0 one with all default options; no more, no less.
freebsd-update -r 12.0-RELEASE upgrade
etc.

Concerning Samba itself, it may has been upgraded with the following command (again from the handbook):
pkg-static upgrade -f
Edit2: the errors are logged before upgrading pkg; as soon as the system boots on 12.0-RELEASE.

I can add that the share is on a zfs dataset and I did run zpool upgrade zroot.
Edit1: I get the error even before upgrading the pool. So this information isn't relevant.

Thanks for your reply.
 
Last edited by a moderator:
Alright so the kernel configuration should not be a problem. I noticed the same behavior (although I run a custom kernel), I think I "solved" it by building samba without quota support from ports. This is only a work around and not really the root cause. Although it does leave my logs clean. I'll try creating a PR if its reproducible in my VM. Also, did you create the directory where you are testing from: "/smb-test" ?
 
Yes, I did with all the rights for anyone. This is just a VM but it reproduces exactly what I get in my bare metal machine. I thought to use the Samba port to get rid of quota support but this would be the last solution for me as I use pkg for all applications.

I've seen that: https://github.com/SpectraLogic/samba/blob/master/source3/lib/sysquotas_4B.c

I wondered if there is any setting in smb4.conf that can avoid quota support.

Anyway, it works as is but I would like to clear this point.
 
I found a way to make these errors stop. Not really a solution, just a clumsy workaround.

smb4.conf(5) states that you can specify a get quota command.
I put under the [global] section:
get quota command=/bin/void

And I created a dumb script named "void":
#! /bin/sh echo "0 0 0 0 0 0 0"

It answers to the quota queries with the right format. The first 0 is a flag that means "no quota".

Nevertheless, the problem is still there. What I did is only cosmetic. Before 12.0-RELEASE, samba used to get an answer for its quota queries. And now, it got nothing because, I guess, there were some changes in the base system.
 
Hi Emrion,
I see the same behaviour on my machine. I'm using a custom kernel (it's just Generic + ALTQ), and I can confirm it happens on samba 4.8 too.

In this mailing list someone is suggesting that some quota api is returning an unexpected error code. This is the relevant snippet.
C:
ret = quotactl(path, cmd, id, qblk);
    if (ret == -1) {
        /* ENOTSUP means quota support is not compiled in. EINVAL
         * means that quotas are not configured (commonly).
         */
        if (errno != ENOTSUP && errno != EINVAL) {
            DEBUG(0, ("failed to %s quota for %s ID %u on %s: %s\n",
                    (cmd & QCMD(Q_GETQUOTA, 0)) ? "get" : "set",
                    (cmd & QCMD(0, GRPQUOTA)) ? "group" : "user",
                    (unsigned)id, path, strerror(errno)));
}

I don't have enough time to debug further in theese days (and probably my C/C++ skills are too rusty for it).
The samba shares are running without client errors, by the way, even if I am experiencing a noticeable slowdown, not in peak tranfer rate, but in accessing files. I don't have enough evidence or benchmark to prove this sencetence, just an impression, but quite strong (since I'm doing the same access pattern often).

I suppose we have to wait for a proper fix, but a PR should be filled, imho.
 
I read quotactl(2) and something clicks to me.
Currently quotas are supported only for the ``ufs'' file system.

My shares belong to a zfs partition.

Tried to mount an ufs partition as a share and you know what? No quota query problem for this one. But still get errors for the zfs share.

For the rest, the error reported by strerror(errno) ("No such file or directory") is like "." can't be anymore understood / translated for a zfs partition.
 
I dug deeper in this problem. I wrote a small code to see what happen:
#include <stdio.h> #include <sys/types.h> #include <ufs/ufs/quota.h> #include <errno.h> #include <string.h> int main(int argc, char* argv[]) { const int nobody = 65534; dqblk dummy; int r = quotactl(".", QCMD(Q_GETQUOTA, USRQUOTA), nobody, &dummy); printf("Ret value = %i\n", r); printf("Err code = %i\n", errno); printf("%s\n", strerror(errno)); return 0; }
If you run that under 12.0 (on a zfs fllesystem), you get :
Ret value = -1
Err code = 2
No such file or directory
This is exactly what samba reports in my case.

And when you run the same under 11.2-p6, you get this:
Ret value = -1
Err code = 45
Operation not supported
You can see in the samba code that this makes false the following test as ENOTSUP is "Operation not supported".
if (errno != ENOTSUP && errno != EINVAL) { DEBUG(0, ("failed to %s quota for %s ID %u on %s: %s\n", (cmd & QCMD(Q_GETQUOTA, 0)) ? "get" : "set", (cmd & QCMD(0, GRPQUOTA)) ? "group" : "user", (unsigned)id, path, strerror(errno)));
This difference of error number returned between 11.2 and 12.0 versions is the cause of the problem.
And I think the error code that comes from the12.0 version has no sense. It's a bug.
 
Until this is fixed in a release I apply the following patch to net/samba48.

Diff:
--- source3/lib/sysquotas_4B.c.orig     2019-01-25 20:41:41 UTC
+++ source3/lib/sysquotas_4B.c
@@ -142,7 +142,7 @@ static int sys_quotactl_4B(const char * path, int cmd,
                 * means that quotas are not configured (commonly).
                 */
                if (errno != ENOTSUP && errno != EINVAL) {
-                       DEBUG(0, ("failed to %s quota for %s ID %u on %s: %s\n",
+                       DEBUG(10, ("failed to %s quota for %s ID %u on %s: %s\n",
                                    (cmd & QCMD(Q_GETQUOTA, 0)) ? "get" : "set",
                                    (cmd & QCMD(0, GRPQUOTA)) ? "group" : "user",
                                    (unsigned)id, path, strerror(errno)));
 
I have a single pkg repo for both ZFS and UFS systems. A couple need UFS quota support for user home dirs. Otherwise I could either rebuild it locally with different options or have multiple repos. Both I'd rather not do.

The patch only shows that message if debug log level is set to 10.
 
Ok, that's a good reason :).

To be honest, I have no idea when and how the official patch will join a RELEASE version.
 
How things work in FreeBSD is that most commits are made on head. When they are back portable to lower versions they will receive an MFC stamp with a period defined. The fix for quatoctl() received "MFC in two weeks". This means that STABLE12 will receive the fix 2 weeks after initial commit on head. Or in other words, 12.1 release will have the fix, as the release versions are "snapshots" from their corresponding stable branch.
 
Just updated and tested a 12.0-STABLE version (r343663). No more "get quota" Samba message for this one.
 
This issue appears to have returned in FBSD 12.1:

Code:
Dec  3 19:21:05 storage smbd[32702]:   failed to get quota for group ID 10000 on .: Operation not permitted
Dec  3 19:21:05 storage smbd[32702]: [2019/12/03 19:21:05.683344,  0] ../../source3/lib/sysquotas_4B.c:155(sys_quotactl_4B)
Dec  3 19:21:05 storage smbd[32702]:   failed to get quota for user ID 10500 on .: Operation not permitted
Dec  3 19:21:05 storage smbd[32702]: [2019/12/03 19:21:05.683508,  0] ../../source3/lib/sysquotas_4B.c:155(sys_quotactl_4B)
Dec  3 19:21:05 storage smbd[32702]:   failed to get quota for group ID 10000 on .: Operation not permitted
 
This issue appears to have returned in FBSD 12.1:

Code:
Dec  3 19:21:05 storage smbd[32702]:   failed to get quota for group ID 10000 on .: Operation not permitted
Dec  3 19:21:05 storage smbd[32702]: [2019/12/03 19:21:05.683344,  0] ../../source3/lib/sysquotas_4B.c:155(sys_quotactl_4B)
Dec  3 19:21:05 storage smbd[32702]:   failed to get quota for user ID 10500 on .: Operation not permitted
Dec  3 19:21:05 storage smbd[32702]: [2019/12/03 19:21:05.683508,  0] ../../source3/lib/sysquotas_4B.c:155(sys_quotactl_4B)
Dec  3 19:21:05 storage smbd[32702]:   failed to get quota for group ID 10000 on .: Operation not permitted
I have two systems with FreeBSD 12.1-RELEASE-p1. One uses Samba48 and the other Samba410. I have no message like you got in both dmesg -a and Samba logs.

By the way, the message was "No such file or directory" not "Operation not permitted". Furthermore, this error code (ENOTSUP) shouldn't generate a message if you read the Samba code above in the thread.

So your case is peculiar. We need more informations like the Samba version you use, the file system where your shares lie and for what operation(s) this message appears .
 
This issue arise for me while running net/samba410 in a FreeBSD 12.0 jail. The ZFS datasets in question are not jailed. Samba see no ZFS:

Code:
$ zfs list
no datasets available

The error I see is:

Code:
Dec 20 22:19:28 fileserver smbd[67236]: [2019/12/20 22:19:28.696043,  0] ../../source3/lib/sysquotas_4B.c:155(sys_quotactl_4B)
Dec 20 22:19:28 fileserver smbd[67236]:   failed to get quota for user ID 1001 on .: Operation not permitted

I used this poudriere solution in a make.conf file:

Code:
net_samba410_UNSET+=QUOTAS
 
It's weird. I think it isn't the same bug. Reading the patch here, the porter has also inhibited the bug in some versions before 12.1. As you can see, the error reported (ENOTSUP) souldn't leave a debug message.

Ok, I confused ENOTSUP and EPERM.

From errno(2)()
EPERM Operation not permitted. An attempt was made to perform an oper-
ation limited to processes with appropriate privileges or to the
owner of a file or other resources.

Maybe it's a jail specific problem? I have no idea how you can use some shares that the jailed samba just doesn't see... Never worked with jails, this can explain that.

So this actually may be a jail specific problem.

It could be of some use to make a bug report concerning this problem even if you found a workaround.
 
Back
Top