Verbinden Netzlaufwerk nicht mehr möglich

german

#1

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


Failed to Open Group Policy Object
#2

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


#3

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


#4

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.


#5

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


#6

Hallo,

hm, kannst du nicht einfach die IP nehmen? :slight_smile:

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)?


#7

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


Samba Shares funktion seit Update auf UCS 4.1.0
Samba Shares funktion seit Update auf UCS 4.1.0
#8

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

[1] - forum.univention.de/viewtopic.ph … 280#p18280


#9

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


#10

Ich habe nach Absprache mit Univention diesen und drei weitere Threads in Bug 40374 zusammengefasst, damit dort die weitere Bearbeitung gebündelt werden kann.


#11

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