[Samba] "Check Names" only supported on single subnet

Matthew Kern mkern at alconconstruction.com
Thu May 26 19:03:08 UTC 2022


Hi,

I'm having a problem with ACLs on my server (Samba 4.13.17 on FreeBSD
13.1-RELEASE). Back in January, I had everything working properly, so that
users with "Full Control" on a directory could edit the ACLs on that
directory to their needs. There have been changes to smb4.conf since it was
initially setup, but no changes since a point I know it was working. There
have been package/system updates since then, of course (including Samba -
as far as I can tell, I was using 4.13.14 back in January). The problem
seems to be related actually to networking, rather than the ACL system -
let me do my best to explain.

There are 3 VLANs that Samba should be listening on (2, 10, 99 on mce0.2,
mce0.l and mce0 respectively, since 99 is PVID/Untagged on that port).
We'll focus on 2 and 99 for now (10 acts identical to 2 in testing). 99 is
a more "privileged" VLAN in my head, but by all means they should be
equivalent in terms of FW rules for everything I describe (FW being between
the VLANs - pf is disabled on this server), leaving the only thing
"special" about 99 being that it's untagged on the server's interface, and
it's the network for the default route. There are several users with access
to the share, but it doesn't seem to matter which one is used (in
particular, one user in "admin users" and the unix wheel group acts
the same way as the rest). The share itself, and *almost* everything in it
are Everyone - Full Control with inheritance enabled. When we want to
"hide" a folder, we'll disable inheritance on that, and add the permissions
we actually want, always using Windows.

When any user connects from a 99 address to the server's 99 address,
everything works fine. When any user connects from a 2 address to either 2
or 99, things fail (see below).
When any user connects from a 99 address to the server's 2 address, things
fail (see below).

The "fail" state is a little wacky: basically, it's possible to modify
ACLs, but not "Check Names", which makes almost every "useful" ACL
modification impossible in Windows. When in the failed state, any time the
Windows "Select User or Group" dialog comes up, entering anything and then
hitting "Check Names" immediately asks for authentication (and nothing
helps) - alternatively, hitting "Advanced" and "Find Now" lists several
"builtin" groups, but not the users (like it does in the success state).
I'm able to, in that failed state, disable inheritance, remove individual
entries, etc., but nothing that requires entering a principal name.

smb4.conf looks like this (clipped out the print$ and printers sections -
we're largely not using samba for printers anymore, and hoping to disable
that anyway soon):
-----
[global]
workgroup=WORKGROUP
netbios name = Castor
security = user
rpc_server:spoolss = external
rpc_daemon:spoolssd = fork
printing = CUPS
spoolss:architecture = Windows x64
admin users = root, mkern
acl allow execute always = yes
interfaces = 172.20.0.7 192.168.10.7 192.168.99.7 127.0.0.1 #tried with
this and next line commented out too - that first is the vlan 2 address,
then 10, then 99.
bind interfaces only = yes
disable netbios = yes #also tried with this and the next line commented out
smb ports = 445

[fdrive]
path = /storage/fdrive
read only = no
mangled names = no
vfs objects = zfsacl shadow_copy2
shadow:snapdir = .zfs/snapshot
shadow:sort = desc
shadow:format = %Y-%m-%d
zfsacl:map_dacl_protected = yes
-----

Where do I even start debugging this one? How does that "Check Names"
function work, and is there another way I can test that? Any other ideas?

Many thanks in advance!
-Matthew Kern


More information about the samba mailing list