[Samba] User cannot access member server share by name, only by IP

Luke Barone lukebarone at gmail.com
Fri Dec 2 20:41:01 UTC 2022


So here's the sad part (for me): some users are showing up still in the
70_000-range, which they should not be. Is there a way to get all the user
ID numbers from the member server's point of view, then re-assign them to
be in the 100_000 range?

On Fri, Dec 2, 2022 at 12:39 PM Luke Barone <lukebarone at gmail.com> wrote:

> I agree, the ID number is weird. I've started creating new groups (Staff2,
> Office2, etc), and they are getting the right ID numbers. I'm in the
> process of adding the users to their new groups, and it seems to be
> helping. I'll rename the groups after I get rid of the originals.
>
> Yes, "DOMAIN" is "edge", I thought I sanitized but apparently not. My goal
> is to have all the users/groups for the domain in the 100_000 to 199_999
> range.
>
> On Fri, Dec 2, 2022 at 10:46 AM Rowland Penny via samba <
> samba at lists.samba.org> wrote:
>
>>
>>
>> On 02/12/2022 18:11, Luke Barone via samba wrote:
>> > I think I found the issue, just not the resolution.
>> >
>> > While researching, I tried to flush the winbind cache. This looked to
>> work
>> > until this morning. The Staff group for the domain has an ID of 70012
>> (for
>> > those paying attention - not part of the domain range, but part of the *
>> > range) on the ACL of the folder, but 101109 when I run `id` while
>> logged in
>> > as a user of that group (and their user ID appears to be 70010!). When I
>> > login as another user in the group, it shows as 70012 in the `id`
>> command
>> > though! The user's ID in this case is 101471.
>> >
>> > Obviously there is an issue with how the usernames are mapped. What I
>> need
>> > to know is how do I move past this? Can I manually change the uid being
>> > reported on the member server for these users to be in the 100_000
>> range?
>> > Or am I at the whim of winbind?
>> >
>> > On Tue, Nov 29, 2022 at 2:32 PM Luke Barone <lukebarone at gmail.com>
>> wrote:
>> >
>> >> To add to this: On the file server, I see this line repeated constantly
>> >> for the computer the user is working on:
>> >>
>> >> [2022/11/29 14:23:36.559926,  0]
>> >> ../../source3/smbd/service.c:166(chdir_current_service)
>> >>    chdir_current_service: vfs_ChDir(/usr/local/share/Staff) failed:
>> >> Permission denied. Current token: uid=70010, gid=100513, 8 groups:
>> 100513
>> >> 101109 70011 101202 70002 70003 70010 70001
>> >>
>> >> I'm feeling that's wrong, given the range in the config file. Is this
>> >> something that can be repaired, or do I have to wipe and redo the
>> >> account(s)?
>> >>
>> >> On Tue, Nov 29, 2022 at 2:18 PM Luke Barone <lukebarone at gmail.com>
>> wrote:
>> >>
>> >>> I have 2 DCs and a member server, all running on Debian Bullseye,
>> version
>> >>> 4.13.13-Debian. Recently, some users cannot access folders that are
>> being
>> >>> shared on the member server.
>> >>>
>> >>> I can run `su -s/bin/bash USERNAME`, then cd into the directory just
>> >>> fine. From the Windows workstation, it's not always working. Most
>> recently,
>> >>> I was able to fix one share by flushing the winbind cache (net cache
>> >>> flush). The other main share they're using is fixed temporarily by
>> mapping
>> >>> to the IP address vs the FQDN (or hostname). This is leading me to
>> think
>> >>> this is a Kerberos issue.
>> >>>
>> >>> The Windows 10 computers are on the 21H2 patch level, which is working
>> >>> for other sites in our organization. Checking on both DCs, replication
>> >>> appears to be working (0 consecutive failures).
>> >>>
>> >>> I saw a previous message about users being part of a group for
>> >>> permissions, but it didn't seem to be my *exact* issue. Is it
>> related? We
>> >>> only add users to the groups, then the groups have permissions on
>> various
>> >>> shares.
>> >>>
>> >>> DC1 smb.conf (DC2 is the same):
>> >>>
>> >>> # Global parameters
>> >>> [global]
>> >>>          bind interfaces only = Yes
>> >>>          disable netbios = Yes
>> >>>          interfaces = lo enp1s0
>> >>>          ntlm auth = ntlmv1-permitted # needed for wireless
>> >>>          passdb backend = samba_dsdb
>> >>>          realm = DOMAIN.CA
>> >>>          server role = active directory domain controller
>> >>>          server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc,
>> drepl,
>> >>> winbindd, ntp_signd, kcc, dnsupdate
>> >>>          winbind separator = /
>> >>>          workgroup = DOMAIN
>> >>>          rpc_server:tcpip = no
>> >>>          rpc_daemon:spoolssd = embedded
>> >>>          rpc_server:spoolss = embedded
>> >>>          rpc_server:winreg = embedded
>> >>>          rpc_server:ntsvcs = embedded
>> >>>          rpc_server:eventlog = embedded
>> >>>          rpc_server:srvsvc = embedded
>> >>>          rpc_server:svcctl = embedded
>> >>>          rpc_server:default = external
>> >>>          winbindd:use external pipes = true
>> >>>          idmap_ldb:use rfc2307 = yes
>> >>>          idmap config * : backend = tdb
>> >>>          map archive = No
>> >>>          vfs objects = dfs_samba4 acl_xattr
>> >>>
>> >>>
>> >>> [netlogon]
>> >>>          path = /var/lib/samba/sysvol/DOMAIN.ca/scripts
>> >>>          read only = No
>> >>>
>> >>>
>> >>> [sysvol]
>> >>>          path = /var/lib/samba/sysvol
>> >>>          read only = No
>> >>>
>> >>> Relevant section on file server:
>> >>> [global]
>> >>>          bind interfaces only = Yes
>> >>>          client signing = required
>> >>>          dedicated keytab file = /etc/krb5.keytab
>> >>>          disable netbios = Yes
>> >>>          interfaces = lo enp1s0
>> >>>          kerberos method = secrets and keytab
>> >>>          log file = /var/log/samba/%m.log
>> >>>          realm = DOMAIN.CA
>> >>>          security = ADS
>> >>>          server role = member server
>> >>>          server signing = required
>> >>>          template homedir = /home/DOMAIN/%U
>> >>>          username map = /etc/samba/user.map
>> >>>          winbind enum groups = Yes
>> >>>          winbind enum users = Yes
>> >>>          winbind refresh tickets = Yes
>> >>>          winbind separator = /
>> >>>          winbind use default domain = Yes
>> >>>          workgroup = DOMAIN
>> >>>          idmap config edge : range = 100000-199999
>> >>>          idmap config edge : backend = rid
>> >>>          idmap config * : range = 70000-99999
>> >>>          idmap config * : backend = tdb
>> >>>          map acl inherit = Yes
>> >>>          vfs objects = acl_xattr
>> >>>
>> >>>
>> >>> [Users]
>> >>>          path = /home/DOMAIN
>> >>>          read only = No
>> >>>
>> >>>
>> >>> [Staff]
>> >>>          path = /usr/local/share/Staff
>> >>>          read only = No
>> >>>
>> >>>
>> >>> [Office]
>> >>>          path = /usr/local/share/Office
>> >>>          read only = No
>> >>>
>> >>>
>> >>>
>>
>> Why is 'staff' getting the GID '70012' ?
>> As you say, that range is meant for the default domain and 'staff'
>> should be a DOMAIN group.
>>
>> Is DOMAIN actually 'edge' as you have set in the 'idmap config' lines ?
>> If it isn't, then change 'edge' to 'DOMAIN' and reload Samba or restart
>> it, but beware, this will give all your users and groups ID's in the
>> 100000-199999 range (which is what they should have).
>>
>> Rowland
>>
>>
>> --
>> To unsubscribe from this list go to the following URL and read the
>> instructions:  https://lists.samba.org/mailman/options/samba
>>
>


More information about the samba mailing list