Benutzer können im Homeverzeichnis nicht löschen/ändern

UCS - Univention Corporate Server
#1

Hallo @all,

ich brauche mal wieder Hilfe:

Nach einem Upgrade unseres UCS Master und Backup von Version 2.3 auf die Version 2.4, können Windows7-Benutzer das eigene Homeverzeichnis auf dem Memberserver zwar sehen, aber nicht mehr draufzugreifen. Windows XP Rechner können zwar zugreifen, lesen und Dateien neu Anlegen, diese aber dann nicht mehr löschen oder umbenennen. Das ist genauso bei Linux-Rechnern.

Es gibt keine Probleme bei dem Homeverzeichnis auf dem Master. Der Memberserver wurde nach dem Upgrade neu gejoined. Der Zugriff auf NFS Freigaben auf dem Memberserver funktioniert auch problemlos.

Ich weiß leider nicht mehr wo ich nach dem Fehler suchen soll. Vergabe einer neuen SID hat schon mal nichts gebracht, außer, dass das Passwort nicht mehr angenommen wurde.

Danke für schnelle Hilfe

Viele Grüße
froeschchen

#2

Hallo,

könnten Sie Ihre Umgebung etwas genauer beschreiben? Werden die Heimatverzeichnisse per NFS auf dem/den Memberservern eingebunden und von dort per Samba an die Clients freigegeben? Läuft auf allen Systemen UCS 2.4? Welche Kernel sind im Einsatz?

Gibt es Fehlermeldungen wenn Sie z.B. Versuchen eine Datei per smbclient zu löschen? Welche Fehlermeldung erhalten Windows 7 Benutzer? Gibt es Meldungen in den Samba-Logdateien der Memberserver?

Mit freundlichen Grüßen
Janis Meybohm

#3

Hallo!
Danke für die schnelle Antwort. Leider hat mich der Grippevirus für ein paar Tage lamgelegt, so dass ich erst jetzt antworten konnte.

Hier nun ein paar nähere Informationen:

Univention Memberserver 2.4-1-0
Kernel 2.6.32-ucs21-686

Univention DC Master 2.4-1-0
Kernel 2.6.32-ucs11-686

Fehlermeldung bei Windows7 das Verzeichnis anzeigen zu lassen:
Auf \x.x.x.x\name konnte nicht zugegriffen werden.
Sie haben keine Berechtigung für den Zugriff auf \x.x.x.x\name. Wenden Sie sich an den Netzwerkadministrator, um den Zugriff anzufordern.

Bei Linux (Kubuntu) beim Umbennnen oder Löschen einer Datei:
Zugriff verweigert auf smb://x.x.x.x/name/Test2.txt

Sowie ich das gesehen habe, werden die Heimatverzeichnisse nicht explizit per nfs gemountet. Im UDM stehen 3 Heimatverzeichnisfreigaben. Alle Freigaben heißen homes. Eine Feigabe vom Backup, eine vom Matrix und eine vom Master selber. Bei den Benutzern ist das Unix Heimatverzeichnis /home/name
Die Heimatverzeichnisfreigabe ist leer sowie auch der Pfad zur Heimatverezichnisfreigabe. Trägt man hier den Benutzernamen ein und in der Heimatverzeichnisfreigabe die Memberserver homes Freigabe, gibt es bezüglich des Zugriffs keine Veränderungen. Beim erstmaligen Eintragen jedoch wurde der Inhalt der Memberserver homes Freigabe nochmals in dem Verzeichnis des Benutzers abgebildet und der Ordner /home/name hatte die Berechtigungen root:root bekommen. Nach mehrmaligen anmelden und abmelden des Benutzers in und aus der Domaine war das aber wieder in Ordnung (warum auch immer). Es kann aber trotzdem nicht zugegriffen werden.

Generell sind die Benutzer nicht in der Domaine, sondern melden sich lokal auf den PCs an.
Aber auch der Test mit einem Benutzer in der Domaine hat nichts geändert.

Ich hoffe diese Informationen helfen weiter.
Vielen Dank schonmal
Gruß froeschchen

#4

Ich hoffe ja nicht, dass mein Beitrag jetzt eingeschlafen ist, nur weil ich mich einmal nicht sofort melden konnte???

Wäre schön, wenn noch mal jemand antwortet!

Danke, Gruß
froeschchen

#5

Hallo,

ich bin etwas unsicher ob ich Ihre Konfiguration richtig verstehe, daher versuche ich mich mal an einer kurzen Zusammenfassung:

3 Server:

  • DC-Master (2.4-1, Kernel 2.6.32)

  • DC-Backup (?, ?)

  • Memberserver (2.4-1, Kernel 2.6.32)

  • Auf allen drei Systemen läuft Samba

  • Auf allen drei Systemen wurde eine Heimatverzeichnisfreigabe angelegt

Daraus ergeben sich für mich einige Fragen:

  • Auf welchem Server sind die Heimatverzeichnisse tatsächlich abgelegt?
  • Warum melden sich die Benutzer nicht gegen die Domäne an?
  • Sind die Windows-Clients in die Domäne gejoint?

Generell würde ich in einer Umgebung dieser Art wie folgt vorgehen:

  • Ein Server stellt die Heimatverzeichnisse bereit (Server A)
  • Heimatverzeichnissfreigaben der anderen beiden Server werden entfernt
  • Entfernen der Home- und Profil-Einstellungen an Benutzerobjekten im UDM
  • UCR samba/homedirserver (und ggf. samba/profileserver) auf allen Servern korrekt setzen (ucr set samba/homedirserver=A; /etc/init.d/samba restart)
  • Join aller Windows-Clients in die Samba-Domäne
  • Anmeldung aller Benutzer gegen die Domäne

Details zur Konfiguration von UCS/Samba finden Sie im Kapitel “Services für Windows” des UCS Handbuchs. Bzgl. Windows 7 beachten Sie bitte außerdem den SDB-Artikel Wie kann ein Windows 7 / Windows 2008 System in eine UCS Domäne eingebunden werden?.

Mit freundlichen Grüßen
Janis Meybohm

#6

Hallo,

Der UCS-Backup hat die version 2.4-1-1
Kernel:2.6.32-ucs11-686

Auf allen dreien läuft der Samba Dienst. Auf allen Dreien ist eine Heimatverzeichnisfreigabe angelegt. Auf die Heimatverezichnisfreigabe des Masters komme ich per Samba drauf und kann alles machen, ebenso mit der Heimatverzeichnisfreigabe des Backups, nur nicht vom Memberserver. Auf dem Memberserver sind die Heimatverzeichnisse abgelegt.

Wir wollen uns prinzipiell nicht in der Domaine anmelden. Die meisten Rechner sind nicht in der Domaine gejoint, es gibt aber ein paar Ausnahmen.

Wir haben festgestellt, dass wir einen WinXP-Client haben der schon vor dem Update auf 2.4 in die Domaine gejoint war und bei dem gibt es für das Homeverzeichnis auf dem Memberserver keine Probleme.

Die Anweisungen werde ich gleich mal befolgen und schauen, ob’s danach funktioniert.

Vielen Dank und Gruß
Froeschchen

#7

Hallo

ich habe die Server angepasst wie Sie es vorgeschlagen haben und einen Windows7 PC (mit Regestry-update) in die Domaine gejoint. Leider hat es keine Veränderung gebracht.

Ich habe mir das Sambalog nochmal angeschaut. Es ist voll mit diesen Einträgen, für jeden Benutzer:

[2011/02/09 09:22:39.802503, 0] passdb/passdb.c:627(lookup_global_sam_name)
User administrator with invalid SID S-1-5-21-2029396578-283276782-2881582584-5010 in passdb

Wie gesagt eine neue SID wurde schon mal erzeugt, mit dem Erfolg, dass das Passwort nicht mehr gültig war.

Mit der Version 2.3-2 war noch alles in Ordnung erst nach dem Update auf Version 2.4 kam das Problem. Was ist da schiefgelaufen, wir haben die Konfigurationen nicht geändert?

Gruß
Froeschchen

#8

Hallo,

wurden in Ihrem LDAP evtl. mehrere Samba-Domänenobjkte angelegt (“ldapsearch -xLLL sambaDomainName=*”)? Betreiben Sie unterschiedliche Domänen auf den drei Servern und was gibt der Befehl “net rpc testjoin” auf dem Memberserver aus?

Mit freundlichen Grüßen
Janis Meybohm

#9

Hallo!

Nein die Server laufen mit genau einem SambaDomänenObjekt. Der Befehl net rpc testjoin gibt aus:

Join to “TEST” is OK

Grüße
Froeschchen

#10

Hallo,

bitte prüfen Sie ob die sambaSIDs und sambaPrimaryGroupSIDs aller Objekte zur Domain-SID passen:

domainSIDs=$(ldapsearch -xLLL sambaDomainName=* sambaSID | sed -ne 's|sambaSID: ||p') echo -e "Domain SIDs:\n$domainSIDs" domainSIDs=$(echo $domainSIDs | tr '\n' '|') for sid in `ldapsearch -xLLL '(|(sambaSID=*)(sambaPrimaryGroupSID=*))' sambaSID sambaPrimaryGroupSID | sed -ne 's|sambaSID: ||p;s|sambaPrimaryGroupSID: ||p'``; do echo $sid | egrep -q "$domainSID" if [ $? -ne 0 ]; then echo "Invalid SID: $sid" fi done

Außerdem sollten Sie prüfen ob es evtl. doppelt vergebene SIDs gibt:

ldapsearch -x -LLL sambaSID=* sambasid | sed -ne 's|sambaSID: ||p' | while read sid; do if [ $(ldapsearch -x -LLL sambaSID=$sid sambasid | grep -c sambaSID) -ne 1 ]; then echo $sid; fi; done

Mit freundlichen Grüßen
Janis Meybohm

#11

Hallo,

Danke für die Antwort.
Ich habe beide Skripte ausprobiert. Beim ersten bekomme ich die Domain SID ausgegeben, beim zweiten bekomme ich keine Ausgabe, also passen die Objekte zur Domain-SID und wir haben auch keine doppelt vergebenen SIDs.

Beim Skript sollte nur ein

 "`" hinter "...||p'``; do "

stehen.

Viele Grüße
froeschchen

#12

Hallo,

ich benötige eigentlich immer noch Hilfe, aber irgendwie geht es hier nur sehr schleppend voran.
Gibt es denn keine Lösung für mein Problem. Können wir unsere Homeverzeichnisse gar nicht mehr nutzen? Ich bin es allmählich müde, von Benutzern angesprochen zu werden, ob ich bitte deren Dateien konsolenseitig umbennen könnte.

Gruß
Froeschchen

#13

Die Problembeschreibung erinnert stark an eine Verhaltensänderung, die bei der Paketierung von Samba 3.5.4 für UCS 2.4 beobachtet wurde (Bug 18425):
Ab Samba 3.4.0 hat sich das Verhalten von Samba bei der Authentifikation von Benutzern mit unbekannter Domänen-Herkunft verändert. Die Änderung wird unter anderem in diesem Posting auf der Samba-Technical Mailingliste erklärt. Um zu prüfen, ob diese Änderung tatsächlich die Ursache der Share-Zugriffsprobleme ist, kann auf den Memberservern die Datei /etc/samba/local.conf um folgende zwei Zeilen erweitert werden:

[global]
   map untrusted to domain = yes

Danach sollte der Samba-Dienst auf dem jeweiligen Server neu gestartet werden. Weitere Hinweise zu dieser Einstellung liefert die Manualseite zu smb.conf.
Wenn die oben beschriebene ‘invalid SID […] in passdb’ Meldung in der log.smbd auf dem Memberserver aufgetreten ist, dann würde ich vermuten, dass S-1-5-21-2029396578-283276782-2881582584 nicht die Domain SID ist, die von dem Skript in dem obigen Posting ausgegeben wurde, sondern die lokale SID des Memberservers (“net getlocalsid”).

Mit freundlichen Grüßen,
Arvid Requate

#14

Hallo,

vielen Dank für die Antwort. Ich habe den Code hinzugefügt und Samba neu gestartet, aber leider kann ich immer noch nichts umbenennen oder löschen.

Die im Logfile angegebene SID ist die der Domäne. Der Befehl “net getlocalsid” gibt auf dem Memberserver folgende Ausgabe:
[2011/02/28 12:04:25.885818, 0] lib/smbldap_util.c:310(smbldap_search_domain_info)
smbldap_search_domain_info: Adding domain info for MEMBER failed with NT_STATUS_UNSUCCESSFUL
SID for domain MEMBER is: S-1-5-21-729550471-2535372647-2628705805

–> Ich habe auf diese Ausgabe hin sicherheitshalber den MEMBER nochmal gejoint, aber die Ausgabe war anschließend immer noch die selbe.

Das Skript von oben gibt diese Ausgabe:
Domain SIDs:
S-1-5-21-2029396578-283276782-2881582584

Auf dem UCS-Master bekomme ich für “net getlocalsid” folgende Ausgabe:
SID for domain UCS is: S-1-5-21-2524237111-2242665017-2008113054

Das Skript von oben liefert auf dem Master dies:
Domain SIDs:
S-1-5-21-2029396578-283276782-2881582584

Leider ist somit die Vermutung nicht eingetroffen :’(
Aber vielleicht geben die neuen Infos mehr Aufschluss?

Vielen Dank und viele Grüße
froeschchen

#15

Hallo,

ich dachte ja, dass jetzt nach so langer Zeit nach der Cebit vielleicht mal wieder eine Antwort gepostet wurde, aber irgendwie scheint mein Problem etwas in Vergessenheit geraten zu sein?

Gibt es vielleicht idealerweise einen anderen Supportweg, wo einem schneller geholfen wird?

Gruß
Froeschchen

#16

Hallo,

hierfür ist unser Support vorgesehen.
Für weitere Informationen zu Konditionen etc. würde ich Sie an unseren Vertrieb (vertrieb@univention.de oder 0421 222 32 20) verweisen.

Mit freundlichen Grüßen
Janis Meybohm

Mastodon