Bug 11887 - After update home shares are invisible (same behavior as if browseable was set to no)
Summary: After update home shares are invisible (same behavior as if browseable was se...
Status: RESOLVED INVALID
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.2.12
Hardware: x64 Linux
: P5 normal (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-02 14:22 UTC by Hannes Wenzel
Modified: 2022-07-18 14:14 UTC (History)
1 user (show)

See Also:


Attachments
relevant smb.conf (1.46 KB, text/plain)
2016-05-04 15:25 UTC, Hannes Wenzel
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hannes Wenzel 2016-05-02 14:22:28 UTC
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?
Comment 1 Stefan Metzmacher 2016-05-03 20:52:46 UTC
Which version did you use before? What's your smb.conf?
Comment 2 Hannes Wenzel 2016-05-04 15:25:48 UTC
Created attachment 12063 [details]
relevant smb.conf
Comment 3 Hannes Wenzel 2016-05-04 15:34:42 UTC
We have updated from 4.1.22.
Comment 4 Hannes Wenzel 2016-05-11 09:54:31 UTC
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 5 Hannes Wenzel 2016-05-11 09:58:06 UTC
Comment on attachment 12063 [details]
relevant smb.conf

>[homes]
>	path = /home/%D/%U
>	path = /home/%D/%S
corrected erroneous path definition in [homes]
Comment 6 Hannes Wenzel 2016-06-10 14:54:39 UTC
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 :)
Comment 7 Rowland Penny 2022-07-10 15:50:59 UTC
(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
Comment 8 Rowland Penny 2022-07-18 14:14:06 UTC
(In reply to Rowland Penny from comment #7)

OK, no one has complained, so closing this. Reason: misconfiguration.