Hi,
Resurrecting an older thread, but this same problem has just
re-occurred following a recent upgrade from 4.2.2 to 4.3.1.
When this issue occurs, I can't access various files on my server
(whether sysvol or other shares) - this seems to be down to incorrect
UID mappings. I am using rfc2307 to set my UIDs, but samba
occasionally seems to ignore this.
I first noticed the problem when a "gpupdate" on one of my client
machines gave me an error, saying it could not read
\\domain\sysvol\domain\Policies\{guid}\gpt.ini from a domain
controller.
After some investigation I found that 'wbinfo -i myuser' on my DC gave
me wrong UID information. Rather than reading from the rfc2307
attributes I have in AD, samba seems to be "making up" UIDs again. In
the example below, my UID should be 41000:
# wbinfo -i myuser
DOMAIN\myuser:*:3000007:100:My Name:/home/DOMAIN/myuser:/bin/bash
The same erroneous UID (3000007) is shown in 'smbstatus' output, also.
The following command fixes it for a little while and reads the info
from AD, as it should.. However, this doesn't last and after some time
it is back to the "made up" UIDs again :-( Here is the command that
fixes it temporarily:
# net cache flush
# wbinfo -i myuser
DOMAIN\myuser:*:41000:61000:My Name:/home/DOMAIN/myuser:/bin/bash
I have the following set in smb.conf - nothing has really changed
since June when I last had this issue.
server services = -dns +winbind -winbindd
idmap_ldb:use rfc2307 = yes
testparm shows the following, after the workgroup/realm/interfaces config:
server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc,
drepl, ntp_signd, kcc, dnsupdate, winbind
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
dsdb:schema update allowed = true
idmap config * : backend = tdb
map archive = No
map readonly = no
store dos attributes = Yes
include = /usr/local/samba/etc/smb.conf-0.0.0.0
vfs objects = dfs_samba4 acl_xattr
I do have sssd configured in nsswitch.conf on the DC itself; this
works fine for logging in on the DC and 'getent' etc.; this issue is
just within Samba and anything accessed across the network via smbd,
as far as I can tell.
I'm not sure what debugging I will be able to do within Samba.. it
seems that some code path is getting triggered that stops looking up
UIDs from LDAP/AD, and instead uses its internal generation mechanism?
:-(
It's certainly intermittent, but does certainly happen. For example, I
end up with meaningless entries such as the UIDs below:
# smbstatus|head
Samba version 4.3.1
PID Username Group Machine Protocol Version
------------------------------------------------------------------------------
16139 3000119 3000016 1.2.3.4 (ipv4:1.2.3.4:62784) SMB2_10
Any help I can give in tracking this down, I gladly will do..!
Cheers
Jonathan
--
"If we knew what it was we were doing, it would not be called
research, would it?"
- Albert Einstein
On 07/11/15 02:29, Jonathan Hunter wrote:> Hi, > > Resurrecting an older thread, but this same problem has just > re-occurred following a recent upgrade from 4.2.2 to 4.3.1. > > When this issue occurs, I can't access various files on my server > (whether sysvol or other shares) - this seems to be down to incorrect > UID mappings. I am using rfc2307 to set my UIDs, but samba > occasionally seems to ignore this. > > I first noticed the problem when a "gpupdate" on one of my client > machines gave me an error, saying it could not read > \\domain\sysvol\domain\Policies\{guid}\gpt.ini from a domain > controller. > > After some investigation I found that 'wbinfo -i myuser' on my DC gave > me wrong UID information. Rather than reading from the rfc2307 > attributes I have in AD, samba seems to be "making up" UIDs again. In > the example below, my UID should be 41000: > > # wbinfo -i myuser > DOMAIN\myuser:*:3000007:100:My Name:/home/DOMAIN/myuser:/bin/bash > > The same erroneous UID (3000007) is shown in 'smbstatus' output, also. > > The following command fixes it for a little while and reads the info > from AD, as it should.. However, this doesn't last and after some time > it is back to the "made up" UIDs again :-( Here is the command that > fixes it temporarily: > # net cache flush > # wbinfo -i myuser > DOMAIN\myuser:*:41000:61000:My Name:/home/DOMAIN/myuser:/bin/bash > > I have the following set in smb.conf - nothing has really changed > since June when I last had this issue. > server services = -dns +winbind -winbindd > idmap_ldb:use rfc2307 = yes > > testparm shows the following, after the workgroup/realm/interfaces config: > server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, > drepl, ntp_signd, kcc, dnsupdate, winbind > 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 > dsdb:schema update allowed = true > idmap config * : backend = tdb > map archive = No > map readonly = no > store dos attributes = Yes > include = /usr/local/samba/etc/smb.conf-0.0.0.0 > vfs objects = dfs_samba4 acl_xattr > > > > I do have sssd configured in nsswitch.conf on the DC itself; this > works fine for logging in on the DC and 'getent' etc.; this issue is > just within Samba and anything accessed across the network via smbd, > as far as I can tell. > > I'm not sure what debugging I will be able to do within Samba.. it > seems that some code path is getting triggered that stops looking up > UIDs from LDAP/AD, and instead uses its internal generation mechanism? > :-( > > It's certainly intermittent, but does certainly happen. For example, I > end up with meaningless entries such as the UIDs below: > > # smbstatus|head > > Samba version 4.3.1 > PID Username Group Machine Protocol Version > ------------------------------------------------------------------------------ > 16139 3000119 3000016 1.2.3.4 (ipv4:1.2.3.4:62784) SMB2_10 > > > Any help I can give in tracking this down, I gladly will do..! > > Cheers > > Jonathan >Is it possible that sssd is failing? What do you have in /etc/nsswitch? It could be that sssd isn't running or running correctly, so it cannot get the required info from AD, so winbind is returning the info from idmap.ldb, hence the '3000000' numbers. Rowland
On 7 November 2015 at 10:11, Rowland Penny <rowlandpenny241155 at gmail.com> wrote:> > Is it possible that sssd is failing? > What do you have in /etc/nsswitch?# cat /etc/nsswitch.conf | egrep "(passwd|group)" passwd: files sss group: files sss But I don't think this is anything to do with sssd. As I understand it: Local machine UNIX use (i.e. logging in via ssh; looking at files on disk via "ls"; etc.) uses sssd, because this is what I have set in nsswitch.conf. This all works fine, I have no problems with this. "SMB file access" (i.e. a Windows client machine elsewhere on the network, accessing resources via \\server\share\path) does not use sssd, but uses smbd + winbind/winbindd for UID resolution? This is the part that is failing intermittently.> It could be that sssd isn't running or running correctly, so it cannot get > the required info from AD, so winbind is returning the info from idmap.ldb, > hence the '3000000' numbers.Does winbind/wbinfo ever query what is defined in /etc/nsswitch.conf, or does it always use the samba internal UID resolution? I thought it would bypass nsswitch.conf entirely - hence my suspicion that this is nothing to do with sssd. It's hard to reproduce this at will - right now "wbinfo -i myuser" is returning correct UID information. The problem (as far as i can tell) is that, every so often, despite me having "idmap_ldb:use rfc2307 yes" in smb.conf, this same wbinfo command returns incorrect UID information (as also shown in "net cache list") and therefore this is why I cannot access files via smbd until I clear the idmap cache via "net cache flush". I'm trying to narrow it down to a particular set of circumstances but it's so intermittent, I'm really struggling. I would raise a bug on bugzilla but I'm not sure there's enough information here for someone familiar with the code to resolve it, yet. It is of course possible that I'm doing something wrong - but the thing that makes me convinced it's a bug is that I have /not/ changed my configuration in any way since June (when I last saw this issue). After my recent upgrade to 4.3 the problem came back - I saw it again last night - but has not reoccurred since then until now.. I really do think there is a subtle bug here. Is it worth me putting all this into a bugzilla entry, even though I haven't yet narrowed down the full circumstances under which it happens? Thanks Jonathan -- "If we knew what it was we were doing, it would not be called research, would it?" - Albert Einstein