Univention Bugzilla – Bug 26142
VFS Objekt acl_xattr auf Samba 3 nicht aktivieren
Last modified: 2012-04-03 16:08:57 CEST
Ich habe nach http://sdb.univention.de/1030 einen Share (auf einem Memberserver) für Profile angelegt, das Dateisystem ist mit user_xattr gemountet. # univention-directory-manager shares/share create \ --position="cn=shares,$ldap_base" \ --option samba --set "name=profiles" \ --set "host=samuel" \ --set "path=/windows-profiles" \ --set sambaBrowseable=0 \ --set sambaWriteable=1 \ --set sambaCreateMode=700 \ --set sambaDirectoryMode=700 # chmod 1777 /windows-profiles Am Benutzer ist als Profilpfad "\\samuel\profiles\%UseName%\Vista" gesetzt. Melde ich micht jetzt an einem Windows 7 Client an, wird das Profilverzeichnis unter /windows-profiles automatisch erzeugt, der Client kann es aber nicht verwenden - man wird mit einem lokalen Profil angemeldet: Ereignis-ID: 1526 Das servergespeicherte Benutzerprofil wurde nicht geladen. Sie werden mit einem lokalen Benutzerprofil angemeldet. Änderungen an dem Profil werden nach der Abmeldung nicht auf den Server kopiert. Das Profil konnte nicht geladen werden, da eine bereits vorhandene Serverkopie des Profilordners die falschen Sicherheitseinstellungen aufweist. Entweder der aktuelle Benutzer oder die Administratorengruppe muss Besitzer dieses Ordners sein. # find /windows-profiles/ -type d -exec getfacl {} \; getfacl: Entferne führende '/' von absoluten Pfadnamen # file: windows-profiles/ # owner: root # group: root # flags: --t user::rwx group::rwx other::rwx getfacl: Entferne führende '/' von absoluten Pfadnamen # file: windows-profiles/cheese # owner: cheese # group: Domain\040Users user::rwx group::--- other::--- default:user::rwx default:group::--- default:other::--- getfacl: Entferne führende '/' von absoluten Pfadnamen # file: windows-profiles/cheese/Vista.V2 # owner: cheese # group: Domain\040Users user::rwx group::--- other::--- default:user::rwx default:group::--- default:other::--- # find /windows-profiles/ -type d -exec getfattr -d {} \; getfattr: Entferne führenden '/' von absoluten Pfadnamen # file: windows-profiles/cheese user.DOSATTRIB=0sMHgxMAAAAwADAAAAEQAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIDp2//X68wBAAAAAAAAAAA= getfattr: Entferne führenden '/' von absoluten Pfadnamen # file: windows-profiles/cheese/Vista.V2 user.DOSATTRIB=0sMHgxMAAAAwADAAAAEQAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIDp2//X68wBAAAAAAAAAAA= Aktiviert man die lokale Gruppenrichtlinie "Eigentümer von servergespeicherten Profilen nicht prüfen" (unter Richtlinien für lokale Computer -> Computerkonfiguration -> Administrative Vorlagen -> System -> Benutzerprofile) wird man ohne Fehlermeldung angemeldet (Verzeichnisse unter /windows-profiles vorher gelöscht), beim Abmelden gibt es aber eine Meldung dass das Profil nicht auf den Server geschrieben werden konnte. Ereignis-ID: 1509 Die Datei C:\Users\cheese\NTUSER.DAT konnte nicht nach \\samuel$NOCSC$\profiles\cheese\Vista.V2\NTUSER.DAT kopiert werden. Möche Fehlerursachen sind Netzwerkprobleme oder nicht ausreichende Sicherheitsrechte. Details - Zugriff verweigert Wenn ich die von Windows erstellten Verzeichnisse lösche und anschließend manuell (ohne DOSATTRIB) neu anlege (mkdir -p /windows-profiles/cheese/Vista.V2; chown cheese:'Domain Users' -R /windows-profiles/cheese/; chmod 700 -R /windows-profiles/cheese/) kann das Profil erfolgreich gespeichert werden. Verzeichnisse unterhalb von /windows-profiles/cheese/Vista.V2 bekommen dann DOSATTRIBs, die manuell erstellten Verteichnisse aber nicht.
Entfernt man die automatisch vom Listerner gesetzte Option "vfs objects = acl_xattr" von dem Share und ergänzt man die Konfiguration durch "profile acls = yes", kann der Windows 7 Client ein Profilverzeichnis selbst anlegen und anschließend auch ohne Fehlermeldungen verwenden. Zu "profile acls" steht in man smb.conf: --- Note that if you have multiple users logging on to a workstation then in order to prevent them from being able to access each others profiles you must remove the "Bypass traverse checking" advanced user right. This will prevent access to other users profile directories as the top level profile directory (named after the user) is created by the workstation profile code and has an ACL restricting entry to the directory tree to the owning user. --- Ich kann in meinen Test aber auch ohne weitere Anpassung weder auf den lokalen Cache des Profils anderer, noch auf dem Server auf die Profile anderer Zugreifen. Auf einem Samba 4 System (im meinem Fall ein DC-Slave) funktionier das Anlegen/Verwenden des Profil-Share auch mit "vfs objects = acl_xattr", "profile acls = yes" ist hier nicht notwendig. In dieser Konstellation werden die Profilverzeichnisse selbst (Vista.V2 etc.) hier immer 770 angelegt, allerdings kann man vom nicht auf die Verzeichnisse andere Zugreifen (auch nicht auf die lokalen Kopien). "vfs objects = acl_xattr" kann als Workaround überschrieben werden indem man im UDM über die "Erweiteren Samba Einstellungen" den Schlüssel "vfs objects" auf ein Leerzeichen setzt.
Für den Einsatz des smbd auf Samba4-DCs haben wir den Patch http://gitweb.samba.org/samba.git/?p=samba.git;a=commit;h=b3b69064d32c921c010b60d12551d450ed4be7c9 Für das samba4-Quellpaket angewendet. Dieser Patch applied genauso auf das samba 3.5.11 Quellpaket. Da das samba-Paket sowieso schon für ucs3.0-1 neu gebaut ist, habe ich daher diesen samba4-Patch jetzt auch für das samba-Quellpaket übernommen. Test steht noch aus.
Zur Info: getfattr -d zeigt nur die ACLs and, die mit "^user\\." beginnen. Um die NTACLs zu sehen ist z.B. "getfattr -d -m '' /var/lib/samba/sysvol/ucs3s4x2.qa" sinnvoll. Also: find /windows-profiles/ -type d -exec getfattr -d -m '' {} \;
(In reply to comment #2) > Test steht noch aus. Habe ich kurz geprüft. Die Verzeichnisse werden mit ACLs angelegt, allerdings ist das Laden/Speichern nicht möglich da Windows meint der Eigentümer sei nicht korrekt. Setze ich "profile acls = yes" bekomme ich in der Windows Ereignissanzeige eine "Zugriff Verweigert"-Meldung.
Das Fehlverhalten lässt sich durch Installation von Winbind auf dem Meberserver beheben. Ohne Winbind hat Samba (v3.5.11) dort spezielle SIDs aus einer speziellen Samba-Domäne für "Unmapped users" in die NTACLs geschrieben. Dies SIDs sind keine Domänen-SIDs, deren RID mit der Posix-ID übereinstimmt. ### SIDs in den NT-ACLs owner: S-1-22-1-2044 group: S-1-22-2-5001 ### IDs des Benutzers im UCS-Managementsystem: uidNumber: 2044 gidNumber: 5001 sambaPrimaryGroupSID: S-1-5-21-3508360685-4114613763-1990273819-513 sambaSID: S-1-5-21-3508360685-4114613763-1990273819-11127 Vorschlag wäre daher, auf Memberservern winbind immer mit zu installieren.
Der Installer sollte winbind eigentlich bei Softwareauswahl Samba3 mit installieren und damit sollten dann korrekte NTACLs geschrieben werden. Damit das in Zukunft auch bei Nachinstallation von unviention-samba direkt funktioniert, ist jetzt Bug 26200 angelegt.
OK, funktioniert. Sobald winbind verfügbar ist, können die SIDs aufgelöst werden.
UCS 3.0-1 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte dieser Bug dupliziert werden: "Clone This Bug"