Since updating to 4.2.11-SerNet-RedHat-20.el7 the home shares in my AD disappeared. I would rule out authorization problems since the files in the share can be looked up. Only the share does not get enumerated when visiting \\svr. Looking through the logs i noticed something in log.smbd: [2016/05/02 13:40:48.851243, 5] ../source3/lib/username.c:181(Get_Pwnam_alloc) Finding user VFA\wenzehan [2016/05/02 13:40:48.851263, 5] ../source3/lib/username.c:120(Get_Pwnam_internals) Trying _Get_Pwnam(), username as lowercase is vfa\wenzehan [2016/05/02 13:40:48.851926, 5] ../source3/lib/username.c:128(Get_Pwnam_internals) Trying _Get_Pwnam(), username as given is VFA\wenzehan [2016/05/02 13:40:48.852345, 5] ../source3/lib/username.c:141(Get_Pwnam_internals) Trying _Get_Pwnam(), username as uppercase is VFA\WENZEHAN [2016/05/02 13:40:48.852702, 5] ../source3/lib/username.c:153(Get_Pwnam_internals) Checking combinations of 0 uppercase letters in vfa\wenzehan [2016/05/02 13:40:48.852741, 5] ../source3/lib/username.c:159(Get_Pwnam_internals) Get_Pwnam_internals didn't find user [VFA\wenzehan]! [2016/05/02 13:40:48.852762, 3] ../source3/smbd/password.c:138(register_homes_share) No home directory defined for user 'VFA\wenzehan' It feels like the wrong username is looked up. The username should come without the prepended domain. I would like to further trace the issue back to its origin, but going through the source code takes quite some understanding. Is there a simple shell equivalent of what Samba does to look the name up?
Which version did you use before? What's your smb.conf?
Created attachment 12063 [details] relevant smb.conf
We have updated from 4.1.22.
Comment on attachment 12063 [details] relevant smb.conf >[global] > workgroup = VFA > realm = AD.VFA.TU-COTTBUS.DE > netbios name = DAT > server string = Datenaustausch/-lagerung > server role = active directory domain controller > dns forwarder = 141.43.1.1 > > log level = 5 auth:10 sam:0 dns:0 msdfs:0 ldb:0 locking:0 > debug class = yes > > idmap_ldb:use rfc2307 = yes > > # nur lokale Profile > logon path = > logon home = > > # Datenfreigabe > hide dot files = No > > # Druckerdienste (deaktiviert) > load printers = no > printing = bsd > printcap name = /dev/null > disable spoolss = yes > > # nicht benötigt > server services = -nbt > smb ports = 445 > disable netbios = yes > > tls enabled = Yes > tls keyfile = tls/dat.key > tls certfile = tls/dat.pem > tls cafile = tls/vfa-ca.pem > > read only = no > # gilt u.a. für autom. erstellte Benutzerverzeichnisse > browseable = yes > > # Provisorium wg âElement nicht gefundenâ beim Verteilen von GRO > # https://lists.samba.org/archive/samba/2013-September/175681.html > host msdfs = yes > >[homes] > path = /home/%D/%S > # \\dat\homes nicht anzeigen > # angezeigt werden sollen die autom. erstellten Benutzerverzeichnisse > # diese erben die globale Einstellung > browseable = no > # Erstelle noch nicht existierende Benutzerverzeichnisse > root preexec = /var/lib/samba/smbh.sh %U > >[lehrstuhl] > path = /home/share > >[netlogon] > path = /var/lib/samba/sysvol/ad.vfa.tu-cottbus.de/scripts > browseable = no > >[sysvol] > path = /var/lib/samba/sysvol > browseable = no > # Provisorium wg GRO s.o. > msdfs root = yes >
Comment on attachment 12063 [details] relevant smb.conf >[homes] > path = /home/%D/%U > path = /home/%D/%S corrected erroneous path definition in [homes]
Hallo, again! I updated and problems persist. Thus I installed the debuginfo-package and tried to find the culprit. It seems like register_homes_share(session_info->unix_info->unix_name) should rather be called like register_homes_share(session_info->unix_info->sanitized_username) in source3/smbd/sesssetup.c . I have cross-checked with another server (of the same version), that does not have this problem. Both servers used gensec_genenerate_session_info_pac() to fill session_info. The bug-free server then calls auth3_generate_session_info_pac() and returns a session_info where unix_name and sanitized_username are identical. My problematic server DAT calls to auth_generate_session_info_pac(). This ends up in auth_session_info_fill_unix(), where unix_name is always prepended by the domain name. It seems natural that register_homes_share() should use sanitized_username instead. Of course, I may miss some parts in the puzzle. Please, mind that I am not familiar with the code base. I would gladly do some tests, for example if there was a means to enforce a certain GENSEC-backend. So far, goodbye and Schönes Wochenende :)
(In reply to Hannes Wenzel from comment #6) I doubt if this bug report is still relevant to the reporter, but it was missed that the '[homes]' share is the only share where you must not set the path variable. It should have been called '[home]' or the path variable not set, though this brings further problems, you cannot use 'valid users' on a DC, so everyone will be able to connect to the share unless the creation script set the correct permissions. If no one complains, I will close this bug in seven days
(In reply to Rowland Penny from comment #7) OK, no one has complained, so closing this. Reason: misconfiguration.