Bug 54200 - No access to home share on member servers
No access to home share on member servers
Product: UCS
Classification: Unclassified
Component: Samba4
UCS 5.0
amd64 Linux
: P5 normal (vote)
: UCS 5.0-1-errata
Assigned To: Julia Bremer
Erik Damrose
Depends on: 54014
Blocks: 54320
  Show dependency treegraph
Reported: 2021-12-06 17:58 CET by akrause
Modified: 2022-01-12 16:45 CET (History)
3 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 5: Major Usability: Impairs usability in key scenarios
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 5: Blocking further progress on the daily work
User Pain: 0.286
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional): Workaround is available
Max CVSS v3 score:


Note You need to log in before you can comment on or make changes to this bug.
Description akrause 2021-12-06 17:58:39 CET
After upgrading from 4.4 errata 1001 to errata 1111, access to home shares is impossible if they are created on member servers. Home shares on Main and Backup DC are working correctly. After granting access to the group Domain Users, access works.

Every other share only accessible for a specific user cannot be accessed with this user if the share exists on a member server.

Users can connect to their home shares via Windows regardless of their location. The above problem only affects Linux clients. I tried to connect with Linux clients and Univention Servers, that belong to another domain.

I created a new testing domain consisting of Main and Backup DC and a member server and could reproduce this problem. 

Comment 1 akrause 2021-12-06 18:05:23 CET
Just to be thourough:

Testing consisted of connecting with smbclient, which always worked.

smbclient -U testdom1/user1 //

On DC servers the ls command lists all files. On member servers missing access rights cause an error message: 

Comment 2 Arvid Requate univentionstaff 2021-12-06 18:44:45 CET

echo -e "[global]\n\twinbind use default domain = yes" >> /etc/samba/local.conf
ucr commit /etc/samba/smb.conf
Comment 3 Arvid Requate univentionstaff 2021-12-06 18:47:46 CET
IIRC this only affects NTLM based authentication. In my tests with smbclient acceess worked when using the FQDN, because smbclient seems to use Kerberos internally in that case. Anyway, the workaround should help. There is an updated upstream patch that will make this unnecessary. We'll probably pick that up during the next occasion.
Comment 4 akrause 2021-12-07 11:56:03 CET
I applied this workaround to all necessary file servers and access to the shares is working now. Thank you.
Comment 5 Julia Bremer univentionstaff 2022-01-11 09:21:45 CET
I removed the old 98_CVE-2020-25717-add-local-nt-token-from-nss.quilt
and instead applied the newer upstream patch that fixes this issue without needing extra configuration in the smb.conf.

This also fixes the problem when accessing homeshares via NTLM that is described in this bug.

The test we added that reproduced this problem was successful.

556a10ef37 Bug #54200: yaml
c1a2105d06 Bug #54200: Revert username map script for nss_ldap
Package: univention-samba
Version: 14.0.5-4A~
Branch: ucs_5.0-0
Scope: errata5.0-1

r19496 Bug #54200: Updated patch for the homeshare access on memberservers
Package: samba
Version: 2:4.13.13-1A~
Branch: ucs_5.0-0
Scope: errata5.0-1
Comment 6 Erik Damrose univentionstaff 2022-01-11 12:07:07 CET
OK: All 46share_access_permissions tests succeed
OK: Patch
OK: Remove usermapping script from univention-samba package and its entry from smb.conf
OK: Yaml