Hallo Freunde,
heute führte ich das Upgrade auf UCS 4.1 aus, seitdem kann ein Win7-Rechner (nicht im AD) nicht mehr auf seine bisherigen Netzlaufwerke zugreifen.
Diese waren bisher auf einem Memberserver angelegt.
Rechner, die im AD angelegt sind können zugreifen.
Was kann das sein, bis etwas ratlos?
Mfg,
Michael
Hallo,
Ist ein direkter Zugriff auf die Freigaben möglich?
Funktioniert das Konto, mit dem die Freigaben auf die Laufwerke zugeordnet waren noch?
Viele Grüße,
Dirk Ahrnke
Hallo Herr Ahrnke,
es ist kein direkter Zugriff auf die Freigaben möglich, sie werden nur angezeigt.
Das Konto ist immernoch dasselbe wie vor dem Update auf UCS 4.1 und funktioniert auch problemlos.
Ein bisschen weiter bin ich auch schon, denn ich kann auf keine Freigabe auf Domänen-Rechner zugreifen,
dagegen klappt der Zugriff auf das NAS problemlos.
Mfg,
Michael
Hallo,
Wird per Hostname/FQDN oder per IP des Servers auf die Freigabe zugegriffen?
Falls per Hostname/FQDN, dann würde ich es zunächst mal mit der IP probieren, um ein DNS/Kerberos-Problem auszuschließen.
Hallo CoffeePad,
gute Idee, per IP klappte es dann auch problemlos mit der Freigabe.
Ein Ping auf den Hostname liefert die richtige IP, wo könnte ich denn da noch nachschauen?
DNS scheint ja zu funktionieren, von Kerberos habe ich nicht wirklich eine Ahnung.
Mfg,
Michael
Hallo,
hm, kannst du nicht einfach die IP nehmen? 
Wenn ich so drüber nachdenke, kann es eigentlich kein Kerberos-Problem sein, da sich nur Clients per Kerberos authentifizieren (können), die in der Domäne sind. Die Anmeldung in deinem Fall wird dann stattdessen über NTLM laufen. Sicherheitshalber: Sind die System-Uhren auf dem Client und dem UCS einigermaßen synchron (weniger als 3 Minuten auseinander)?
Hallo CoffePad,
die Zeiten liegen eine Minute auseinander.
Mich hat die ganze Sache nur gewundert, da ich unmittelbar davor das Update auf UCS 4.1 machte,
da hätte es natürlich nahe liegen können.
Mfg,
Michael
Hallo,
Gleiche Frage wie hier [1]:
Funktioniert das Folgende?
a) Vom Fileserver oder DC aus per host
b) Vom Windows-Client aus z.B. per nslookup
Mit freundlichem Gruß,
Jens Thorp-Hansen
Hallo Herr Thorp-Hansen,
ich verfolge den äquivalenten Thread, war aber “etwas” abgelenkt.
[quote=“Thorp-Hansen”]Hallo,
Gleiche Frage wie hier [1]:
Funktioniert das Folgende?
a) Vom Fileserver oder DC aus per host [/quote]
root@ucsserver:~# host fileserver.yyyyy.intranet
fileserver.yyyyy.intranet has address 192.168.0.253
[quote]b) Vom Windows-Client aus z.B. per nslookup
[/quote]
[code]C:\nslookup fileserver.yyyyy.intranet
Server: ucsserver.yyyyy.intranet
Address: 192.168.0.254
Name: fileserver.yyyyy.intranet
Address: 192.168.0.253[/code]
Mfg,
Michael
Ich habe nach Absprache mit Univention diesen und drei weitere Threads in Bug 40374 zusammengefasst, damit dort die weitere Bearbeitung gebündelt werden kann.
Hallo @all,
ich habe nun die folgenden UCR-Variablen auf allen dc’s und bdc’s sowie auch auf allen Fileservern gesetzt:
ucr set samba/interfaces/bindonly=yes
ucr set samba/interfaces="eth0"
service samba restart
Nach dem neustart des Samba Dienstes funktioniert jetzt der Zugriff auf alle Shares auf allen Servern.
Auch die übergabe eines falschen Passworts wird auf nicht Homeshares wie erwartet quittiert.
Beim Homeshare bekommen ich bei einem falschen Passwort die Meldung der Netzwerkname ist nicht verfügbar. Das ist vermutlich normal. Ich kann das derzeit nicht beurteilen.
Ich würde behaupten wollen dieses Vorgehen schon einmal erfolglos durchgetestet zu haben. Ich habe aber seit dem mindestens ein neues Update eingespielt.
Vielen Dank für die Unterstützung.
Mit freundlichen Grüßen
Hendrik Dreyer