Samba Shares funktion seit Update auf UCS 4.1.0

Noch einmal Hallo,

meine Aussage, dass Shares nicht funktionieren muss ich teilweise revidieren.
Shares funktionieren nicht im internen Netz. Sobald ich irgendwie einen Router dazwischen habe, also aus einem anderen Subnetz komme, kann ich auch auf die CIFS-Shares zugreifen!

Dies ist mein internes Netz: 10.0.0.0/24 .
Der Fileserver hat die IP 10.0.0.40, der DC die 10.0.0.41.
Mein Client ist im Bereich 10.0.0.100 - 200. Von hier kann ich nicht auf irgendwelche CIFS-Shares zugreifen.
Sobald ich mich via VPN einwähle habe ich die IP 10.1.0.2 und kann sofort auf alle Shares zugreifen.

Wenn ich mir intern eine Linux VM als Router aufsetze mit der IP 10.0.0.50 im internen Netz und der IP 192.168.1.1 im gerouteten Subnetz (beide in der gleichen Broadcastdomain auf eth0 (eth0:0 & eth0:1), meinem Client gebe ich dann z.B. die IP 192.168.1.100 kann ich ebenfalls auf die Shares zugreifen.

Wenn ich nun meinen Linux-Router herunterfahre und meinem Client die 10.0.0.50 gebe, habe ich wieder das alte Problem.
Ich kann auf keine Shares mehr zugreifen!

Mit freundlichen Grüßen

Hendrik Dreyer

Kannst du mal “ucr set samba/max/protocol=smb2; invoke-rc.d samba restart” auf dem DC Master ausführen und schauen ob das etwas ändert? Das ist die von Samba am höchsten zu verwendende SMB Version - falls ein Client damit nicht klar kommt würde er auf eine niedrigere Version zurückfallen, negative Auswirkungen sind also nicht zu befürchten.

Hallo,

vielen Dank für die Antwort. Ich habe auf dem Master DC die Variable gesetzt und dann versucht auf die Shares zuzugreifen.
[ul]\dc1\netlogon
\fs1\homeshare
\fs2\common[/ul]
Das Problem bleibt gleich.
Danach habe ich die Variable auch auf den Fileservern gesetzt und den Zugriff erneut getestet. Immer noch mit dem gleichen Problem.

Unter einer UCS Maschine habe ich versucht einen CIFS Share zu mounten. Hier bekomme ich den folgenden Fehler:

mount -t cifs //fs2.domain.tld/share /mnt/test -o user=username,password=password mount: wrong fs type, bad option, bad superblock on //fs02.intern.3er-online.de/common, missing codepage or helper program, or other error (for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.<type> helper program) In some cases useful info is found in syslog - try dmesg | tail or so

Versuche ich auf die gleiche Art und Weise einen Share von einem Windows-Client (also der Share wird vom Windows-Client beteitgestellt) zu mounten, funktioniert dies ohne Probleme.

Die Ausgabe von smbclient --list=dc1.domain.tld -U username zeigt die Shares des jeweiligen Systems an.

Mit freundlichen Grüßen

Hendrik Dreyer

Hallo,

ich habe den Test soeben nocheinmal von externen Clients aus einem anderen IP-Adressbereich wiederholt:

[code]C:\Users\hdr>net use * \dc1.domain.tld\netlogon /user:NBDOMAIN\username
password
Laufwerk Z: ist jetzt mit \dc1.domain.tld\netlogon verbunden.

Der Befehl wurde erfolgreich ausgeführt.[/code]

Hier funktioniert es weiterhin. Intern ist ein Arbeiten aber weiterhin nicht möglich.

Mit freundlichen Grüßen

Hendrik Dreyer

Und noch einmal Hallo,

ich habe nun nocheinmal versucht CIFS-Shares zu mounten in dem ich anstelle des DNS- oder Hostnamens die IP angebe.
Das hat funktioniert!

Ich bin nun ein kleines Stück weiter. Ich kenne so ein ähnliches verhalten von Storagesystemen. Dort aber muss in der Regel der Name anstelle der IP übergeben werden.
Ich muss nochmal Recherchieren was ich dazu finde.

Remote funktioniert es mit DNS- oder Hostnamen als auch mit der IP.

Mit freundlichen Grüßen

Hendrik Dreyer

Hallo,
Vielen Dank für den Hinweis. Ich meine hier [1] ein Muster zu erkennen und gebe das entsprechend zur Prüfung weiter.

Die Hinweise auf die IP-Subnetze könnten allerdings auch auf ein DNS-Problem hinweisen und damit ggf. auf Probleme bei Kerberos und/oder den “UNC Hardened Access” (das sind Änderungen, die über MS15-014 eingeführt wurden und UNC Pfade betreffen).

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.p … 06&p=17837

Hallo,

ich wünsche ein frohes neues Jahr.
Hostnamen zu IP und umgekehrt lassen sich intern als auch extern auflösen.
Ein Ping auf den Namen dc1 gibt auch Antwort vom dc1.domain.tld .
An und für sich klappt der Zugriff via DNS-Namen auf alle Server von intern und extern.

Der Zugriff auf \fs1.domain.tld oder \fs2.domain.tld klappt zunächst. Ich bekomme die auf dem Server bereitgestellten Shares an.
Sobald ich nun versuche einen Share zu öffnen kommt der Logindialog (unter Windows)
Ab dem Moment bekomme ich den besagten Fehler angezeigt, der Netzwerkname sei nicht mehr erreichbar.

Einzige Ausnahme ist der Domaincontroller. Auf diesen kann ich nur nach Eingabe des Benutzernamens und Kennworts zugreifen noch bevor irgendwelche Shares angezeigt werden.

Mit freundlichen Grüßen

Hendrik Dreyer

Hallo,

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.
Besagter Trick mit dem Router im Netz funktioniert aber für alle Computer, ebal ob Domainmitglied oder nicht.

Unter Linux gibt es immer das Problem mit dem CIFS-Share. Ich habe aber noch keine Kerberos-Anmeldung via Linux getestet.

mit freundlichen Grüßen

Hendrik Dreyer

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:

  1. 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.

  2. 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

Mastodon