Ich versuche, einen Client mit Ubuntu 13.04 mit einer Netzwerkfreigabe zu verbinden, die von einem Dateiserver gehostet wird, der vor Kurzem von Windows Server 2003 auf 2012 aktualisiert wurde.
Derzeit kann ich die Remote-Freigabe mounten, während ich mit dem LAN verbunden bin, und zwar mit:
sudo mount -t cifs //myserver.mydomain.co.uk/myshare /media/myshare/ -o user=myself,domain=myworkgroup,pass=**********
Ich habe jedoch Probleme, die Freigabe über ein Cisco (IPsec/Xauth) VPN zu mounten. Vor dem Server-Upgrade hatte ich damit kein Problem, aber jetzt erhalte ich die folgende Meldung:
mount error(112): Host is down
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
dmesg | tailgibt mir[ 1975.651346] CIFS VFS: cifs_mount failed w/return code = -112
Der Host ist definitiv nicht ausgefallen. Ich kann weiterhin über VPN eine Verbindung zur gleichen Freigabe herstellen, und zwar mit smbclient:
smbclient //myserver.mydomain.co.uk/myshare -U myself -W myworkgroup
Enter myself's password:
session request to MYSERVER.MYDOMAIN failed (Called name not present)
Domain=[MYWORKGROUP] OS=[Windows Server 2012 Standard 9200] Server=[Windows Server 2012 Standard 6.2]
smb: \>
Ich bin mir über die Bedeutung des session request to MYSERVER.MYDOMAIN failed (Called name not present)Fehlers " " nicht sicher, da ich immer noch in der Lage bin, die Verzeichnisstruktur zu durchsuchen.
Irgendwelche Vorschläge, was Sie als Nächstes versuchen sollten?
Antwort1
Sie können sich mit dem SMB-Client verbinden, da Sie sich als „anonym“ anmelden können. Aber nur weil Sie sich als anonym anmelden können, heißt das nicht, dass der Authentifizierungsdienst für normale Benutzer funktioniert.
Sie haben wahrscheinlich ein Firewall-Problem. Öffnen Sie diese 4 Ports:
- UDP&TCP/137
- UDP&TCP/138
- UDP&TCP/139
- TCP/445
Überprüfen Sie, ob Sie dem Netlogon-Dienst auf der Windows-Seite ebenfalls die Kommunikation gestatten.
Antwort2
Können Sie auf Port 445/tcp zugreifen, wenn Sie sich über VPN verbinden? Verwenden Sie
nc -v myserver.mydomain.co.uk 445.
Wenn es geklappt hätte.
Connection to myserver.mydomain.co.uk 445 port [tcp/microsoft-ds] succeeded!
Das einzige Problem, das Sie möglicherweise sehen, ist, wenn die Firewall die Verbindung, die möglicherweise hergestellt wird, trotzdem erfolgreich über einen Proxy sendet. Dann sollten Sie eine Paketerfassung durchführen und prüfen, ob der Windows-Server etwas sendet.
Antwort3
Nun, ein Jahr später habe ich es endlich herausgefunden!
Die eigentliche Ursache war ein Problem mit der Hostnamenauflösung. Der Hinweis kam, als ich versuchte, ein anderes Problem zu lösen, indem ich über das VPN per SSH auf einen Rechner im selben Remote-Netzwerk zugegriffen habe.
Aus der Ausgabe von ssh -v:
debug1: Connecting to myserver2.mydomain.ox.ac.uk [163.1.21.182] port 22.
Ich habe festgestellt, dass OpenSSH versucht hat, eine Verbindung zu einer unsinnigen IP-Adresse herzustellen (es hat tatsächlich den Hostnamen meines Servers in die IP-Adresse eines Netzwerkdruckers aufgelöst!). Ich habe festgestellt, dass es pingauch Hostnamen nicht richtig aufgelöst hat, während es hostzu funktionieren schien. Das hat mich schließlich zudieser Threadauf Ask Ubuntu.
Es stellt sich heraus, dass pingund sshbeide den glibc-Resolver verwenden, ebenso wie mount.cifs. Die Quellen, aus denen glibc Name-Service-Informationen bezieht, werden in konfiguriert/etc/nsswitch.conf.
Der Inhalt meiner Datei nsswitch.confsah ursprünglich so aus:
passwd: compat
group: compat
shadow: compat
hosts: files myhostname mdns4_minimal [NOTFOUND=return] dns wins mdns4
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
Wichtig ist die Zeile, die mit beginnt hosts:. Sie listet die Reihenfolge der Quellen auf, die glibc bei der Hostnamenauflösung abfragt. Beachten Sie, dass in meiner Version in der Suchreihenfolge dnsdanach kommt .[NOTFOUND=return]
Meine Interpretation ist, dass glibc, wenn es nicht gelingt, den Hostnamen gemäß den ersten vier Quellen aufzulösen, zurückkehrt, bevor es tatsächlich DNS-Server abgefragt hat! Ich habe keine Ahnung, warum es nsswitch.confso konfiguriert wurde (ich habe es bestimmt nicht so eingerichtet), aber die Zeile zu ändern in:
hosts: files myhostname mdns4_minimal dns [NOTFOUND=return] wins mdns4
plötzlich funktionierte alles richtig, einschließlich ping, sshund mount.cifs.