On 13/06/15 11:00, Jonathan Hunter wrote:> On 13 June 2015 at 09:34, buhorojo <buhorojo.lcb at gmail.com> wrote: >>> On 12 June 2015 at 08:55, Jonathan Hunter <jmhunter1 at gmail.com> wrote: >>> Sadly, even though sssd is now running and I'm no longer reliant on >>> winbind, the rest of samba doesn't seem to be taking notice of these >>> mappings - again, only after a period of time (it's OK at first, but >>> then switches to the wrong mappings). >> Then you must have some winbind(d) nonsense stlll. Remove the .tdb s and >> killall winbindd processes. Make sure the idmap_ldb line is removed. Make >> sure only winbind is running at samba start up (I think it's +winbind, >> -winbindd) and lose all refrences to winbind in nsswitch.conf. net cache >> flush doesn't work. You need to remove the databases. >> HTH > Thank you! > > I now set in smb.conf: > > server services = -dns +winbind -winbindd > > I stopped samba, then removed databases: > > # rm /usr/local/samba/var/cache/gencache.tdb \ > /usr/local/samba/var/lock/gencache_notrans.tdb \Restore this:> /usr/local/samba/private/idmap.ldb> > However I must have done something wrong...
Hi buhorojo, I *think* I have a stable system for the moment... so thank you :-) On 13 June 2015 at 12:50, buhorojo <buhorojo.lcb at gmail.com> wrote:>> I now set in smb.conf: >> >> server services = -dns +winbind -winbindd >> >> I stopped samba, then removed databases: >> >> # rm /usr/local/samba/var/cache/gencache.tdb \ >> /usr/local/samba/var/lock/gencache_notrans.tdb \ > > Restore this: >> >> /usr/local/samba/private/idmap.ldbI have the following in smb.conf: server services = -dns +winbind -winbindd idmap_ldb:use rfc2307 = yes and no 'winbind' lines anywhere. I removed /usr/local/samba/var/cache/gencache.tdb and /usr/local/samba/var/cache/gencache_notrans.tdb, and kept /usr/local/samba/private/idmap.ldb (copied from other DC) Now, when starting samba, I see stable connections using the correct UID, even after some time: # smbstatus [....] Locked files: Pid Uid DenyMode Access R/W Oplock SharePath Name Time -------------------------------------------------------------------------------------------------- 14717 41000 DENY_NONE 0x100081 RDONLY NONE /data/sharename . Sat Jun 13 12:58:52 2015 14717 41000 DENY_NONE 0x100081 RDONLY NONE /home/auser Documents Sat Jun 13 15:44:42 2015 7330 41012 DENY_NONE 0x100081 RDONLY NONE /data/anothershare . Sat Jun 13 16:25:40 2015 22048 41001 DENY_ALL 0x100080 RDONLY NONE /home . Sat Jun 13 13:01:03 2015 There is nothing shown at all in 'net cache list'; I guess this is fine (certainly, things seem to work at the moment) Looks like a working minimal configuration for file serving from a DC is the following, then: - use rfc2307 UIDs (sadly, this is a must - I *wish* I could use some kind of algorithmic mapping, ideally sssd's logic, but any really!) - use sssd with 'ldap_id_mapping = False', and specify 'sss' for passwd and group in /etc/nsswitch.conf - Specify 'idmap_ldb:use rfc2307 = yes' in smb.conf - Add '+winbind -winbindd' to 'server services =' in smb.conf -- "If we knew what it was we were doing, it would not be called research, would it?" - Albert Einstein
On 13/06/15 17:33, Jonathan Hunter wrote:> Hi buhorojo, > > I *think* I have a stable system for the moment... so thank you :-) > > On 13 June 2015 at 12:50, buhorojo <buhorojo.lcb at gmail.com> wrote: >>> I now set in smb.conf: >>> >>> server services = -dns +winbind -winbindd >>> >>> I stopped samba, then removed databases: >>> >>> # rm /usr/local/samba/var/cache/gencache.tdb \ >>> /usr/local/samba/var/lock/gencache_notrans.tdb \ >> Restore this: >>> /usr/local/samba/private/idmap.ldb > I have the following in smb.conf: > server services = -dns +winbind -winbinddthis is also winbind:> idmap_ldb:use rfc2307 = yesLose it.> and no 'winbind' lines anywhere. > - use rfc2307 UIDs (sadly, this is a must - I *wish* I could use some > kind of algorithmic mapping, ideally sssd's logic, but any really!)If you want consistency, you can't. You have to read nss information from the ad database. Anyway, well done:)
On 13/06/15 16:33, Jonathan Hunter wrote:> Hi buhorojo, > > I *think* I have a stable system for the moment... so thank you :-) > > On 13 June 2015 at 12:50, buhorojo <buhorojo.lcb at gmail.com> wrote: >>> I now set in smb.conf: >>> >>> server services = -dns +winbind -winbindd >>> >>> I stopped samba, then removed databases: >>> >>> # rm /usr/local/samba/var/cache/gencache.tdb \ >>> /usr/local/samba/var/lock/gencache_notrans.tdb \ >> Restore this: >>> /usr/local/samba/private/idmap.ldb > I have the following in smb.conf: > server services = -dns +winbind -winbindd > idmap_ldb:use rfc2307 = yes > and no 'winbind' lines anywhere. > > I removed /usr/local/samba/var/cache/gencache.tdb and > /usr/local/samba/var/cache/gencache_notrans.tdb, and kept > /usr/local/samba/private/idmap.ldb (copied from other DC) > > Now, when starting samba, I see stable connections using the correct > UID, even after some time: > > # smbstatus > [....] > Locked files: > Pid Uid DenyMode Access R/W Oplock > SharePath Name Time > -------------------------------------------------------------------------------------------------- > 14717 41000 DENY_NONE 0x100081 RDONLY NONE > /data/sharename . Sat Jun 13 12:58:52 2015 > 14717 41000 DENY_NONE 0x100081 RDONLY NONE > /home/auser Documents Sat Jun 13 15:44:42 2015 > 7330 41012 DENY_NONE 0x100081 RDONLY NONE > /data/anothershare . Sat Jun 13 16:25:40 2015 > 22048 41001 DENY_ALL 0x100080 RDONLY NONE > /home . Sat Jun 13 13:01:03 2015 > > There is nothing shown at all in 'net cache list'; I guess this is > fine (certainly, things seem to work at the moment) > > Looks like a working minimal configuration for file serving from a DC > is the following, then: > - use rfc2307 UIDs (sadly, this is a must - I *wish* I could use some > kind of algorithmic mapping, ideally sssd's logic, but any really!) > - use sssd with 'ldap_id_mapping = False', and specify 'sss' for > passwd and group in /etc/nsswitch.conf > - Specify 'idmap_ldb:use rfc2307 = yes' in smb.conf > - Add '+winbind -winbindd' to 'server services =' in smb.conf > >OK, I have a couple VMs running Debian Wheezy with Sernet Samba 4.2.1 These are running as a test domain with two DCs, both are using the built-in dns server and winbindd. If I check smb.conf on both DCs: root at testdc1:~# cat /etc/samba/smb.conf # Global parameters [global] workgroup = SAMBADOM realm = SAMBADOM.EXAMPLE.COM netbios name = TESTDC1 server role = active directory domain controller dns forwarder = 8.8.8.8 idmap_ldb:use rfc2307 = yes load printers = no printing = bsd printcap name = /dev/null disable spoolss = yes [netlogon] path = /var/lib/samba/sysvol/sambadom.example.com/scripts read only = No [sysvol] path = /var/lib/samba/sysvol read only = No root at testdc2:~# cat /etc/samba/smb.conf # Global parameters [global] workgroup = SAMBADOM realm = SAMBADOM.EXAMPLE.COM netbios name = TESTDC2 server role = active directory domain controller dns forwarder = 8.8.8.8 idmap_ldb:use rfc2307 = yes load printers = no printing = bsd printcap name = /dev/null disable spoolss = yes [netlogon] path = /var/lib/samba/sysvol/sambadom.example.com/scripts read only = No [sysvol] path = /var/lib/samba/sysvol read only = No They are both Identical apart from the 'netbios name' Checking 'server services' give this: root at testdc1:~# samba-tool testparm -v | grep 'server services' server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd, ntp_signd, kcc, dnsupdate, dns /etc/nsswitch.conf on both machines have these two lines: passwd: compat winbind group: compat winbind If I check what is running: root at testdc1:~# ps ax | grep '/usr/sbin' | grep "\-D" 2446 ? Ss 0:00 /usr/sbin/samba -D 2637 ? S 0:00 /usr/sbin/samba -D 2638 ? S 0:02 /usr/sbin/samba -D 2639 ? Ss 0:00 /usr/sbin/smbd -D --option=server role check:inhibit=yes --foreground 2640 ? S 0:00 /usr/sbin/samba -D 2641 ? S 0:00 /usr/sbin/samba -D 2642 ? S 0:00 /usr/sbin/samba -D 2643 ? S 0:00 /usr/sbin/samba -D 2644 ? S 0:00 /usr/sbin/samba -D 2645 ? S 0:02 /usr/sbin/samba -D 2646 ? S 0:00 /usr/sbin/samba -D 2647 ? S 0:00 /usr/sbin/samba -D 2648 ? S 0:00 /usr/sbin/samba -D 2649 ? S 0:00 /usr/sbin/samba -D 2650 ? S 0:00 /usr/sbin/samba -D 2651 ? Ss 0:00 /usr/sbin/winbindd -D --option=server role check:inhibit=yes --foreground 2654 ? S 0:00 /usr/sbin/winbindd -D --option=server role check:inhibit=yes --foreground 2755 ? S 0:00 /usr/sbin/winbindd -D --option=server role check:inhibit=yes --foreground If I check a couple of users, one with a uidNumber & gidNumber, the other without: root at testdc1:~# getent passwd user1 user1:*:10003:10000::/home/SAMBADOM/user1:/bin/false root at testdc1:~# getent passwd user2 user2:*:3000016:10000:Jane Doe:/home/SAMBADOM/user2:/bin/false Do the same on the other DC: root at testdc2:~# getent passwd user1 user1:*:10003:10000::/home/SAMBADOM/user1:/bin/false root at testdc2:~# getent passwd user2 user2:*:3000015:10000:Jane Doe:/home/SAMBADOM/user2:/bin/false root at testdc2:~# cat /etc/samba/smb.conf As you can see, the one with the RFC2307 attributes gives the same result on both machines, the other gives different uidNumbers. If I now give the second user the required RFC2307 attributes: root at testdc1:~# samba-tool user nisadd user2 --nis-domain=sambadom --login-shell=/bin/bash --unix-home=/home/user2 User 'user2' updated successfully Try again: root at testdc1:~# getent passwd user2 user2:*:3000016:10000:Jane Doe:/home/SAMBADOM/user2:/bin/false root at testdc1:~# net cache flush root at testdc1:~# getent passwd user2 user2:*:10004:10000:Jane Doe:/home/SAMBADOM/user2:/bin/false And on the other DC: root at testdc2:~# getent passwd user2 user2:*:3000015:10000:Jane Doe:/home/SAMBADOM/user2:/bin/false root at testdc2:~# net cache flush root at testdc2:~# getent passwd user2 user2:*:10004:10000:Jane Doe:/home/SAMBADOM/user2:/bin/false This way of mapping hasn't changed with the replacement of the 'winbind' built into the samba daemon with the separate 'winbindd' daemon. Rowland
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