Hallo,
erneut eine kleine Aktualisierung.
Ich wollte heute gerne eine Windows XP VM in die Domäne fahren. Dies war leider nicht möglich. Die Fehlermeldung lautet auch hier:
Der angegebene Netzwerkname ist nicht mehr verfügbar.
Mit einer Windows 7 Workstation hatte es geklappt!
Mit freundlichen Grüßen
Hendrik Dreyer
Hallo,
noch eine Ergänzung. Ich habe versucht von einem Windows XP Computer, Mitglied in einer fremden Domain, einen Share auf dem Fileserver fs1.domain.tld zu mappen.
Das klappt weder per Hostnamen, FQDN oder IP. Ein Zugriff ist grundsätzlich nicht möglich.
Mit freundlichen Grüßen
Hendrik Dreyer
Hallo Herr Thorp-Hansen,
die Beschreibung im Thread [url]Verbinden Netzlaufwerk nicht mehr möglich] klingt genau wie das von mir beschriebene Problem in diesem Thread.
Ich schlage vor wir arbeiten im anderen Thread weiter um eine Lösung zu finden.
Ich werde dann nach einer Lösungsfindung diesen Thread entsprechend aktualisieren.
Mit freundlichen Grüßen
Hendrik Dreyer
Hallo Hendrik,
ich lese auch hier mit und bin für weitere Test’s bereit.
Mfg,
Michael
Am Sa Jan 02, 2016 21:00 schrieb hendrix3er:
ich habe heute zu Testzwecken eine Windows 7 VM in die Domäne gefahren. Mit dieser funktioniert der Zugriff auf Shares im internen Netz via FQDN auf alle betreffenden Systeme.
Nicht-DomainComputer können nicht auf Shares über den FQDN zugreifen wenn sie sich im internen Netz befinden.
Verstehe ich das richtig, dass die berichteten Probleme beim Share-Zugriff ausschließlich auf Client-Systemen zu beobachten sind, die nicht in die Domäne gejoined sind?
Ich habe nach Absprache mit Univention diesen und drei weitere Threads in Bug 40374 zusammengefasst, damit dort die weitere Bearbeitung gebündelt werden kann.
Um mögliche Ursachen einzugrenzen bzw. kollaterale Effekte schrittweise auszuschliessen, könnte man die Samba-Prozesse testweise so konfigurieren, dass sie geziehlt nur das relevante Netzwerkinterface verwenden:
ucr set samba/interfaces/bindonly=yes samba/interfaces=“eth0”
service samba restart
Zwei weitere Fragen:
Tritt das Problem auch beim Zugriff auf \dc1\netlogon auf? Falls ja, dann würde ich vorschlagen damit erstmal weiter zu testen, um die Anzahl der beteiligten Komponenten möglichst gering zu halten.
Die Logdatei vom Dez 14, 2015 15:03 beschränkt sich leider auf die Ausgaben des smbd-Prozesses. Es könnte informativ sein, auch die Log-Ausgaben anderer beteiligter Samba-Prozesse auf dem fraglichen Server zu protokollieren (winbindd, nmbd und “samba” selbst). Für einen erneuten Zugriffstest wäre daher zu empfehlen vorher den samba/debug/level zu erhöhen und alle beteiligten Samba-Komponenten neu zu starten:
ucr set samba/debug/level=10
service samba restart
Da die unter /var/log/samba geschriebenen Dateien mit dieser Einstellung recht schnell anwachsen, ist zu empfehlen, nach Abschluss des Tests samba/debug/level entsprechend wieder auf 1 zu setzen.
Hallo,
bitte entschuldigen Sie die lange Wartezeit. Ich war im Projekt und habe auch keine Mails mehr über aktualisierungen mehr erhalten!?!
Das Problem tritt auch auf allen DC’s auf. Während ich auf den Fileservern die Shares sehen kann, auf diese aber nicht zugreifen kann, kann ich auf die Domaincontroller überhaupt gar nicht zugreifen.
Der Zugriff auf \fileserver1 oder \fileserver2 klappt, auf \fileserver1\share hingegen schlägt fehl.
Der Zugriff auf \dc1 oder \bdc1 klappt nicht. Auch auf \dc1\netlogon schlägt immer fehl.
Allerdings können Domänenmitglieder (Win7) auf Shares zugreifen. Ich bekomme aber keinen neuen Computer mehr in die Domäne!
Die Fehlermeldung ist immer gleich.
Mit freundlichen Grüßen
Hendrik Dreyer
Hallo,
ich habe nun die folgenden UCR-Variablen auf allen dc’s und bdc’s sowie auch auf allen Fileservern gesetzt:
samba/interfaces/bindonly=yes
samba/interfaces=“eth0”
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 is 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
Hallo,
wenn noch interesse an Logs besteht, ich habe die nicht funktionierende Testumgebung noch verfügbar.
Ich kann das Problem also noch nachstellen und zwar ab dem Zeitpunkt als es noch funktionierte also vor UCS 4.1, über das Update mit dem der Zugriff via CIFS nicht mehr funktioniert bis hin zur gelösten Version.
Vielen Dank nocheinmal an alle beteiligten!
Mit freundlichen Grüßen
Hendrik Dreyer
Hallo,
Allerdings können Domänenmitglieder (Win7) auf Shares zugreifen.
Ich bekomme aber keinen neuen Computer mehr in die Domäne!
Meinen Sie damit, dass Sie keine neuen Windows-Rechner in die Domäne joinen können
oder dass Sie von un-gejointen Windows-Rechnern nicht auf shares zugreifen können?
ich habe nun die folgenden UCR-Variablen auf allen dc’s und bdc’s sowie auch auf allen Fileservern gesetzt:
samba/interfaces/bindonly=yes
samba/interfaces=“eth0”
Als dauerhafte Einstellung würde ich empfehlen auch das loopback-Interface mit aufzunehmen:
ucr set samba/interfaces="lo eth0" samba/interfaces/bindonly=yes
service samba restart
Mit freundlichen Grüßen,
Arvid Requate
Hallo,
gejointe Rechner können auf Shares zugreifen. Nicht gejointe Rechner kommen nicht in die Domäne.
In dem Moment in dem ich den FQDN der Domäne angebe und auf ok klicke, dauert es relativ lange bis die Meldung erscheint: “Der Netzwerkname ist nicht mehr verfügbar.”
Aktuell stehe ich aber nun vor dem Problem, dass ich auf keinen Share mehr zugreifen kann, wenn ich außerhalb des lokalen Netzes bin. Also genau umgekehrt wie zuvor.
Ich habe allerdings noch nicht das Loopback-Interface eingetragen. Dass werde ich nochmal nachholen und das Resultat hier dann melden.
Vielen Dank!
Mit freundlichen Grüßen
Hendrik Dreyer
Hallo,
ich habe das Loopback Interface nun entsprechend mit eingetragen.
Bez. des CIFS-Zugriffs aus einem externen Netz habe ich noch einmal einen vorher nacher Test gemacht.
Es hatte in beiden Fällen entgegen meiner zuvor getroffenen Aussage funktioniert. Vermutlich gab es ein anderes Problem beim ersten Test.
Mit freundlichen Grüßen
Hendrik Dreyer