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

Matthew Kern mkern at alconconstruction.com
Thu May 26 19:23:42 UTC 2022

...of course, I work on this all day and figure it out just *after* I post
on the mailing list. Issue was actually new rules I just rolled out on the
endpoints (Windows built-in firewall) related to File and Printer Sharing -
reverting those changes leaves everything in a working state again. I just
wasn't thinking of those changes as potentially breaking.

Issue is not related to Samba - please ignore!

-Matthew Kern

On Thu, May 26, 2022 at 1:03 PM Matthew Kern <mkern at alconconstruction.com>

> 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 = #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