Samba, ZFS and FreeBSD 12
Carmel NY
carmel_ny at outlook.com
Sat Jan 19 10:42:57 UTC 2019
On Fri, 18 Jan 2019 14:28:23 +0100 (CET), Trond Endrestøl stated:
>On Fri, 18 Jan 2019 13:17-0000, Carmel NY wrote:
>
>> On Fri, 18 Jan 2019 13:30:53 +0100 (CET), Trond Endrestøl stated:
>>
>> >On Fri, 18 Jan 2019 12:08-0000, Carmel NY wrote:
>> >
>> >> On Fri, 18 Jan 2019 12:51:42 +0100, Luciano Mannucci stated:
>> >>
>> >> >On Fri, 18 Jan 2019 12:38:20 +0100 (CET)
>> >> >Trond Endrestøl <Trond.Endrestol at fagskolen.gjovik.no> wrote:
>> >> >
>> >> >> The logs keep filling up:
>> >> >>
>> >> >> Jan 18 12:36:31 <daemon.err> hostname smbd[2115]: [2019/01/18
>> >> >> 12:36:31.841720,
>> >> >> 0] ../source3/lib/sysquotas_4B.c:148(sys_quotactl_4B) Jan 18
>> >> >> 12:36:31 <daemon.err> hostname smbd[2115]: failed to get
>> >> >> quota for group ID 65534 on .: No such file or directory
>> >> >Is your zfs pool status OK? what does zpool status say?
>> >> >
>> >> >Luciano.
>> >>
>> >> # zpool status
>> >> pool: zroot
>> >> state: ONLINE
>> >> status: Some supported features are not enabled on the pool. The
>> >> pool can still be used, but some features are unavailable.
>> >> action: Enable all features using 'zpool upgrade'. Once this is
>> >> done, the pool may no longer be accessible by software that does
>> >> not support the features. See zpool-features(7) for details.
>> >> scan: scrub repaired 0 in 0 days 00:10:17 with 0 errors on Fri
>> >> Dec 21 07:10:14 2018 config:
>> >>
>> >> NAME STATE READ WRITE CKSUM
>> >> zroot ONLINE 0 0 0
>> >> ada0p3 ONLINE 0 0 0
>> >>
>> >> errors: No known data errors
>> >
>> >I think I solved it.
>> >
>> >If Samba is compiled with support for quota, but we don't intend to
>> >use that feature, we may simply set this global option:
>> >
>> >get quota command = /bin/echo 0 0 0 0 0 0 0 1024
>> >
>> >A more sophisticated solution is to
>> >create /usr/local/sbin/query_quota or something similar, and let it
>> >adhere to the specification found in smb.conf(5):
>> >
>> >This parameter should specify the path to a script that queries the
>> >quota information for the specified user/group for the partition
>> >that the specified directory is on.
>> >
>> >Such a script is being given 3 arguments:
>> >
>> >directory
>> >
>> >type of query
>> >
>> >uid of user or gid of group
>> >
>> >The directory is actually mostly just "." - It needs to be treated
>> >relatively to the current working directory that the script can also
>> >query.
>> >
>> >The type of query can be one of:
>> >
>> >1 - user quotas
>> >
>> >2 - user default quotas (uid = -1)
>> >
>> >3 - group quotas
>> >
>> >4 - group default quotas (gid = -1)
>> >
>> >This script should print one line as output with spaces between the
>> >columns. The printed columns should be:
>> >
>> >1 - quota flags (0 = no quotas, 1 = quotas enabled, 2 = quotas
>> >enabled and enforced)
>> >
>> >2 - number of currently used blocks
>> >
>> >3 - the softlimit number of blocks
>> >
>> >4 - the hardlimit number of blocks
>> >
>> >5 - currently used number of inodes
>> >
>> >6 - the softlimit number of inodes
>> >
>> >7 - the hardlimit number of inodes
>> >
>> >8 (optional) - the number of bytes in a block(default is 1024)
>> >
>>
>> I just got this back from the Samba mailing list:
>>
>> You're getting this due to the error code being returned in errno
>> not being one that Samba expects. Here's the underlying code:
>>
>> 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)));
>> }
>>
>>
>> Looks like your system is returning ENOENT here in errno, not ENOTSUP
>> or EINVAL.
>>
>> Is this a bug that I should report?
>
>Yes, please do. And you may also suggest to the Samba team to enhance
>this one and other error messages by spelling out which errno value
>the call returned. Informative error messages are underrated, IMO.
A fix has supposedly been created.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234413
--
Carmel
More information about the freebsd-questions
mailing list