Solved Samba 4.1 problems (I think)

mariourk

mariourk

We're running a FreeBSD 9.1 server with ZFS and use it as a fileserver. Netatalk-2.2.5 for the Macs and Samba-4.1.17 for the PC's. And it works great! Except I ran into some problems, after I updated the server last week. During this update, I upgraded Samba36 to Samba41, because Samba36 isn't supported anymore, apparently.
Code: 
===>>> This port is marked IGNORE
===>>> ADS support requires GSSAPI_BASE, GSSAPI_HEIMDAL, or GSSAPI_MIT


===>>> If you are sure you can build it, remove the
          IGNORE line in the Makefile and try again.
Instead of messing around in the makefile, I opted to upgrade to Samba-4.1. I had to do it at some point anyway. But this caused 2 problems. And I'm not sure how to fix it. I'm not even sure if it's Samba-4.1 causing them.

The first is that I see lots (lots!) of these errors in the logs:
Code: 
Mar 24 09:07:42 prepress smbd[35888]: [2015/03/24 09:07:42.441096,  0] ../source3/modules/vfs_posixacl.c:171(smb_ace_to_internal)
Mar 24 09:07:42 prepress smbd[35888]:   unknown tag type 64
As far as I can tell, this has something to do with ZFS. And yes, all my shares are on ZFS.

The second problem is that all of a sudden I got some calls, that network shares didn't seem to work anymore. When I checked to see what was going on, I saw lots of these in the log files:
Code: 
kern.maxfiles limit exceeded by uid 0, please see tuning(7)
I fixed this by increasing the limit:
sysctl kern.maxfiles=4096000

To be honest, I have no idea how (un)realistic this value is. But it seems to work, for now. However, I am afraid this only deals with the symptoms and not the cause. I do suspect Samba-4.1. After all, I never had this problem before upgrading from Samba36.

Any help, tips and insights would be most welcome.

Thanks in advance! :)
 
Last edited by a moderator:
Hi,

It seems that the same error was observed already in the past. This thread could hep you : Thread smbd-module-acl-error.35851. But if it is related to your problem, I wonder why it did not show up before in your case. By the way, you should upgrade to FreeBSD 9.3.
 
Thanks! I'll look into it.

By the way, you should upgrade to FreeBSD 9.3.
Click to expand...
Now you mention it. Can I upgrade directly from 9.1 to 9.3? Or do I have to upgrade to 9.2 first?
 
The procedure to upgrade properly from 9.1 to 9.3 is described in the handbook. If you are happy with FreeBSD 9.X, I do not see any reason (but I can be wrong) to go for FreeBSD 10.1. Both the 9.3 and 10.1 version EoL are planned for December 31, 2016 which leaves you plenty of time.
 
I added the zpool options and restarted Samba. As suggested in this thread, provided by hukadan. And it made these errors go away:
Code: 
Mar 24 09:07:42 prepress smbd[35888]: [2015/03/24 09:07:42.441096, 0] ../source3/modules/vfs_posixacl.c:171(smb_ace_to_internal)
Mar 24 09:07:42 prepress smbd[35888]: unknown tag type 64
So, thanks for that. :)

That leaves me with the issue of these errors:
Code: 
kern.maxfiles limit exceeded by uid 0, please see tuning(7)
It worries me a little bit, since I have no clue why these errors showed, all of a sudden. Was it because of the Samba upgrade? And was it because of the ZFS-ACL problems, who are fixed now? So, did it fix this problem as well? Or not? Or was it simply because Samba-4 handles things differently and I simply needed to raise that limit? Or does this problem still exist and will face again sooner or later?

Is there any way to monitor how close the system is to this limit? Of I can monitor that, I can see if the system keeps getting closer and closer. Or if if falls back, depending of the load. In that case there is nothing to worry about, I guess.

Any thoughts on the value 4096000?
 
A little update. I applied these options to the Samba4 configuration, to fix the ZFS ACL issues
Code: 
unix extensions = no
nt acl support = yes
inherit acls = no
map acl inherit = yes
vfs objects = zfsacl
nfs4:mode = special
nfs4:acedup = merge
nfs4:chown = yes
They set in the [global] settings, since all my shares are on ZFS. And according to this thread that shouldn't be a problem.

So, error gone. But now the group doesn't seem to have write-access anymore. Only the actual user can edit a file. Anyone in the group (who should have write-access too) can't.

What's going on here? This has to do with the ZFS ACL settings, right? How do I set this straight?
 
mariourk said:
Thanks! I'll look into it.

Now you mention it. Can I upgrade directly from 9.1 to 9.3? Or do I have to upgrade to 9.2 first?
Click to expand...

It should work as long as it's the most recent 9.1-RELEASE-pXX level. All of these errata notes would be applied in that case. Some folks who I had seen having upgrade issues on the forums were running FreeBSD 9.0-RELEASE so they didn't have the fixes to freebsd-update(8).

https://www.freebsd.org/security/advisories/FreeBSD-EN-13:04.freebsd-update.asc
https://www.freebsd.org/security/advisories/FreeBSD-EN-13:05.freebsd-update.asc
https://www.freebsd.org/security/advisories/FreeBSD-EN-14:13.freebsd-update.asc

mariourk said:
Code: 
kern.maxfiles limit exceeded by uid 0, please see tuning(7)
...
Any thoughts on the value 4096000?
Click to expand...

The default was surprisingly low on FreeBSD 9.x. Here's the default on my FreeBSD 10.1 amd64 NAS:
sysctl kern.maxfiles
Code: 
kern.maxfiles: 523140
 
Sorry for not replying, the last few days. I was knocked down by the flu. But I'm ok now :)

Anyway, I've been doing some more digging. According to this thread, the kern.maxfiles errors are indeed caused by Samba-4, generating all these ACL warnings. So, that explains where that came from, all of a sudden. And getting rid of these ACL warnings seems to fix the whole issue and everything should work normal again.

But I still don't know how to fix this permission issue. As soon as I put this in smb4.conf:
Code: 
unix extensions = no
nt acl support = yes
inherit acls = no
map acl inherit = yes
vfs objects = zfsacl
nfs4:mode = special
nfs4:acedup = merge
nfs4:chown = yes
The ACL warnings go away. So, it seems a step in the right direction. But as soon as I do that, the permissions don't seem to apply anymore. Only the owner of a file has write-access. Anyone in the group can't write anymore, despite the fact that the group should have write-access too.

What is going wrong here? And how do I fix this? This ACL stuff is completely new to me. :/
 
After setting the correct ACL permissions for the group, it works fine. I also edited the inheritance permissions for the owner.
Code: 
setfacl -b -m owner@:rwxp--aARWcCos:fd----:allow /path/to/share
setfacl -b -m group@:rwxp--aARWcCos:fd----:allow /path/to/share
So far, no problems, no more ACL warnings from Samba and no choking server with lots of kern.maxfiles limit exceeded errors.
 
You must log in or register to reply here.
Back
Top