Zugriff auf den Gastgeberrechner MacBook Pro OS X 10.8.5 aus einem Virtuellen Gastrechner mit OS WIN NT 4 SP6a
Auf dem MacBook Pro ist VirtualBox (VB) von Oracle installiert. In dem VB sind die vorletzten drei WIN OS Virtuelle Maschinen (VM) wie NT, XP und WIN 7 implementiert. Es funktioniert alles zufriedenstellend was ein PC braucht, außer bei der VM WIN NT nicht.
Die Lösung, die ich brauche, ist der reversible Zugriff über LAN auf die frei deklarierten Ressourcen der VMs von Allen in der Arbeitsgruppe des LANs zueinander auch zu dem Gastgeberrechner dem MacBook Pro. Nur beim NT VM kommt vor, dass sich die VM WIN NT von dem Gastgeberrechner zugreifen lässt, aber nicht umgekehrt; der Zugriff zu anderen VMs aus VM NT ist normal möglich.
Das LAN ist mit TCP/IP prtotokol mit aktiviertem DHCP erstellt. Die Ethernet Adapters sind von VB emuliert. Der Gasgeberrechner antwortet sowohl mit IP-Adressenangabe als auch mit dem Namensangabe nach der Pingeingabe in dem CDM aus allen VMs. In dem Gasgeberrechner antworten alle VMs nur mit der IP-Adressenangabe. Der Versuch die Resource des Gasgeberrechners in die NT VM einzubinden mit dem Befehl "net use * \\Gastgeberrechner\Resource *" endet mit der Meldung: "Systemfehler 53 ist aufgetreten. Der Netzwerkpfad wurde nicht gefunden." Die gleiche Meldung kommt nach dem zweimaligen Anklicken der Gastgeberrechner-Ikone in dem Netzwerkumgebung-Fenster.
Die ipconfig/all Antwort lautet:
C:\>ipconfig/all
Windows NT IP-Konfiguration
Host-Name . . . . . . . . . : nt4sp6a
DNS-Server. . . . . . . . . :
Knotentyp . . . . . . . . . : Broadcast
NetBIOS-Bereichs-ID . . . . :
IP-Routing aktiviert. . . . : Nein
WINS-Proxy aktiviert. . . . : Nein
NetBIOS-Auswertung mit DNS : Nein
Ethernet-Adapter AMDPCN2:
Beschreibung. . . . . . . . : AMD PCNET Family Ethernet Adapter
Physikalische Adresse . . . : 08-00-27-F3-E6-80
DHCP aktiviert. . . . . . . : Ja
IP-Adresse. . . . . . . . . : 192.168.56.6
Subnet Mask . . . . . . . . : 255.255.255.0
Standard-Gateway. . . . . . :
DHCP-Server . . . . . . . . : 192.168.56.1
Lease erhalten. . . . . . . : Sonntag, 5. Oktober 2014 14:15:20
Lease läuuft ab. . . . . . . : Sonntag, 5. Oktober 2014 14:35:20
C:\>net use * \\josefs-mac\users *
Geben Sie das Kennwort für \\josefs-mac\users ein:
Systemfehler 53 aufgetreten.
Der Netzwerkpfad wurde nicht gefunden.
Hat jemand schon ein solches lokales Netwerk ohne Router zwischen NT VM und dem Gastgeberrecher mit OS X konfiguriert?
Bitte herzlichst um Antworten.
Die Lösung, die ich brauche, ist der reversible Zugriff über LAN auf die frei deklarierten Ressourcen der VMs von Allen in der Arbeitsgruppe des LANs zueinander auch zu dem Gastgeberrechner dem MacBook Pro. Nur beim NT VM kommt vor, dass sich die VM WIN NT von dem Gastgeberrechner zugreifen lässt, aber nicht umgekehrt; der Zugriff zu anderen VMs aus VM NT ist normal möglich.
Das LAN ist mit TCP/IP prtotokol mit aktiviertem DHCP erstellt. Die Ethernet Adapters sind von VB emuliert. Der Gasgeberrechner antwortet sowohl mit IP-Adressenangabe als auch mit dem Namensangabe nach der Pingeingabe in dem CDM aus allen VMs. In dem Gasgeberrechner antworten alle VMs nur mit der IP-Adressenangabe. Der Versuch die Resource des Gasgeberrechners in die NT VM einzubinden mit dem Befehl "net use * \\Gastgeberrechner\Resource *" endet mit der Meldung: "Systemfehler 53 ist aufgetreten. Der Netzwerkpfad wurde nicht gefunden." Die gleiche Meldung kommt nach dem zweimaligen Anklicken der Gastgeberrechner-Ikone in dem Netzwerkumgebung-Fenster.
Die ipconfig/all Antwort lautet:
C:\>ipconfig/all
Windows NT IP-Konfiguration
Host-Name . . . . . . . . . : nt4sp6a
DNS-Server. . . . . . . . . :
Knotentyp . . . . . . . . . : Broadcast
NetBIOS-Bereichs-ID . . . . :
IP-Routing aktiviert. . . . : Nein
WINS-Proxy aktiviert. . . . : Nein
NetBIOS-Auswertung mit DNS : Nein
Ethernet-Adapter AMDPCN2:
Beschreibung. . . . . . . . : AMD PCNET Family Ethernet Adapter
Physikalische Adresse . . . : 08-00-27-F3-E6-80
DHCP aktiviert. . . . . . . : Ja
IP-Adresse. . . . . . . . . : 192.168.56.6
Subnet Mask . . . . . . . . : 255.255.255.0
Standard-Gateway. . . . . . :
DHCP-Server . . . . . . . . : 192.168.56.1
Lease erhalten. . . . . . . : Sonntag, 5. Oktober 2014 14:15:20
Lease läuuft ab. . . . . . . : Sonntag, 5. Oktober 2014 14:35:20
C:\>net use * \\josefs-mac\users *
Geben Sie das Kennwort für \\josefs-mac\users ein:
Systemfehler 53 aufgetreten.
Der Netzwerkpfad wurde nicht gefunden.
Hat jemand schon ein solches lokales Netwerk ohne Router zwischen NT VM und dem Gastgeberrecher mit OS X konfiguriert?
Bitte herzlichst um Antworten.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 250994
Url: https://administrator.de/contentid/250994
Ausgedruckt am: 24.11.2024 um 02:11 Uhr
36 Kommentare
Neuester Kommentar
Was ist denn ein "Gasgeberrechner" ??
Gibts den nur für Porschefahrer ?
P.S.: So einen peinlichen Fauxpas kann man mit einem simplen Klick auf "Bearbeiten" wieder korrigieren.
Sollte man eigentlich immer vorher machen bevor man einen Thread auf die Allgemeinheit loslässt ?!
Zurück zum Thread....
Der Bridge Mode stellt eine Verbindung auch nach draussen über die physische NIC des VM Hosts dar.
Ist das nicht gewollt dann muss die NIC im Host Mode arbeiten, damit sind dann der VM Host und die VM einzig und allein nur intern und untereinander im VM Host zu erreichen ohne Connectivity nach draussen.
Fragt sich was von dir hier gewollt ist ?
Nochas zu deinen Namen:
Ohne einen DNS verbreitet Windows Namen über UDP Broadcasts. Es mag sein das der VM Host diese blockt und deshalb Namen unbekannt sind.
Die kannst du aber auf dem Mac jederzeit statisch in die Datei etc/hosts z.B. mit Textedit oder dem nano Editor nachpflegen, dann funktionieren auch Namen.
Bei Winblows ist das die hosts oder auch lmhosts Datei, die man auch einfach mit einem Editor diese Namen bekannt geben kann. Das funktioniert dann immer und unabhängig von Broadcasts.
Wie das bei Winblows zu machen ist kannst du diesem Forumsthread entnehmen:
XP-Home mit 2 Kabelgebundenen und WLAN PCs
Damit klappt das dann auf Anhieb !
Gibts den nur für Porschefahrer ?
P.S.: So einen peinlichen Fauxpas kann man mit einem simplen Klick auf "Bearbeiten" wieder korrigieren.
Sollte man eigentlich immer vorher machen bevor man einen Thread auf die Allgemeinheit loslässt ?!
Zurück zum Thread....
der reversible Zugriff über LAN auf die frei deklarierten Ressourcen der VMs von Allen in der Arbeitsgruppe des LANs zueinander auch zu dem Gastgeberrechner dem MacBook Pro.
Das ist ja kinderleicht wenn man die virtuellen NICs an den VMs im Bridge Mode konfiguriert zum Host !aber nicht umgekehrt;
Wäre aber normal sollte die lokale Firewall dort aktiv sein !Die Ethernet Adapters sind von VB emuliert.
Klar, wichtig wäre hier aber der Modus in dem diese NICs emuliert sind.Der Bridge Mode stellt eine Verbindung auch nach draussen über die physische NIC des VM Hosts dar.
Ist das nicht gewollt dann muss die NIC im Host Mode arbeiten, damit sind dann der VM Host und die VM einzig und allein nur intern und untereinander im VM Host zu erreichen ohne Connectivity nach draussen.
Fragt sich was von dir hier gewollt ist ?
Nochas zu deinen Namen:
Ohne einen DNS verbreitet Windows Namen über UDP Broadcasts. Es mag sein das der VM Host diese blockt und deshalb Namen unbekannt sind.
Die kannst du aber auf dem Mac jederzeit statisch in die Datei etc/hosts z.B. mit Textedit oder dem nano Editor nachpflegen, dann funktionieren auch Namen.
Bei Winblows ist das die hosts oder auch lmhosts Datei, die man auch einfach mit einem Editor diese Namen bekannt geben kann. Das funktioniert dann immer und unabhängig von Broadcasts.
Wie das bei Winblows zu machen ist kannst du diesem Forumsthread entnehmen:
XP-Home mit 2 Kabelgebundenen und WLAN PCs
Damit klappt das dann auf Anhieb !
OK, das macht die Sache klarer.
Du hast auf dem VHost vermutlich NAT (IP Adress Translation) auf den virtuellen Netzwerkkarten konfiguriert. Deshalb hast du auch die "Einbahnstrasse" bei der Erreichbarkeit, da die andere Richtung durch die NAT Firewall verhindert wird.
Du musst also den Modus der V NICs im V Host umstellen, damit du ein transparentes Routing machen kannst.
Knackpunkt bei dir ist also einzig und allein der Modus der virtuellen Netzwerkkarten im VHost. Wenn du das richtig setzt kommt das sofort zum Fliegen.
Du hast auf dem VHost vermutlich NAT (IP Adress Translation) auf den virtuellen Netzwerkkarten konfiguriert. Deshalb hast du auch die "Einbahnstrasse" bei der Erreichbarkeit, da die andere Richtung durch die NAT Firewall verhindert wird.
Du musst also den Modus der V NICs im V Host umstellen, damit du ein transparentes Routing machen kannst.
Knackpunkt bei dir ist also einzig und allein der Modus der virtuellen Netzwerkkarten im VHost. Wenn du das richtig setzt kommt das sofort zum Fliegen.
Die Neztwerkadapters sind beim allen VM's im Host-only Mode gewählt worden.
OK, das erzwingt dann unbedingt das du das IP Forwarding, sprich Routing aktivierst auf den Windows OS so wie es in diesem_Tutorial beschrieben ist !Das gilt auch für OS-X, denn das Guest OS muss ja dann zwingend routen können zwischen den IP Netzwerken an den NICs um eine Kommunikation sicherzustellen.
Unter OS-X wird mit sysctl -w net.inet.ip.forwarding=1 IP Forwarding im Betriebssystem aktiviert !
Im Default ist das wie bei Winblows und Liunx immer deaktiviert !
Mit den Treibern oder SMB hat das nix zu tun. SMB ist ja lediglich ein Sharing Protokoll was mit dieser Thematik nichts zu tun hat.
Das das Pingen der Guesthosts nur mit deren IPs klappt, ist klar, denn das Name Service Broadcasting funktioniert mit vNICs im Host Modus nicht.
Hier nochmals der Appell das in die Datei hosts oder lmhosts fest und statisch einzutragen wenn deine Guesthosts ein Winblows Betriebssystem nutzen.
Unter OS-X ist das die Datei /etc/hosts
Die kannst du z.B. mit dem nano Editor editieren und dein Guestshosts Namen dazutragen ala
MacBook:etc user$ cat hosts
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
##
127.0.0.1 localhost
255.255.255.255 broadcasthost
10.1.1.1 guesthost1
10.1.1.2 guesthost2
::1 localhost
fe80::1%lo0 localhost
Andersrum mit Windows genauso.
Nur mal ganz blöd nachgefragt:
Hast du auf dem OS-X Host die Firewall aktiv ?? (Apfel - Systemeinstellungen - Sicherheit)
Wenn das der Fall ist lässt OS-X wie alle anderen OS auch generell keine Verbindungen von außen zu !!
Ist das der Fall bei dir deaktivierst du temporär mal die Firewall oder trägst entsprechende Ausnahmen in die Firewall Regeln ein !!
Hast du auf dem OS-X Host die Firewall aktiv ?? (Apfel - Systemeinstellungen - Sicherheit)
Wenn das der Fall ist lässt OS-X wie alle anderen OS auch generell keine Verbindungen von außen zu !!
Ist das der Fall bei dir deaktivierst du temporär mal die Firewall oder trägst entsprechende Ausnahmen in die Firewall Regeln ein !!
Ich habe heute noch einmal probiert temporer bei deaktivierter Firewall die VM zu starten und mit dem OS X Host zu verbinden. Vergäblich. Immer ist der Systemfehler 53 die Meldung.
Hast du bei deaktiviert Firewall überhaupt erstmal überprüft ob du den VMHost dann von der VM auch anpingen kannst ??Ein erfolgreicher Ping ist Grundvoraussetzung das es überhaupt funktioniert, denn das verifiziert eine aktive IP Verbindung !!
Deinen VM hat ja einen IP 192.168.56.2 wenn man das richtig sieht. Folglich muss dein OS-X Host ja auch einen Adapter in diesem IP Netz haben !
Mit dem OS-X Terminalbefehl ifconfig kannst du das sehen !
Vermutlich ist das die 192.168.56.1, richtig ? Kannst du diese IP von der NT4 VM anpingen ?? Das muss funktionieren !
Lieder hast du ja recht spärliche bis keine Infos zur OS-X Adapterkonfig
vmboxnet0 ist das virtuelle Netzwerk Interface auf dem Mac zur VM. Es hat ja auch die entsprechende IP Adresse.
Dadurch das du es fehlerfrei Pingen kannst siehst du das die Netzwerk Connectivity fehlerlos funktioniert !
Du solltest also fehlerfrei auf Dienste unter OS-X von NT aus (VM) zugreifen können und auch umgekehrt von OS-X auf NT.
Das kannst du ganz einfach mal testen wenn du unter NT ein Terminalprog. Wie PuTTY installierst und eine SSH Session auf den OS-X Rechner 192.168.56.1 auchmachst.
Auch ein Mounting von SMB Shares auf OS-X müsste mit Start - Ausführen \\192.168.56.1\<name_verzeichnis problemlos möglich sein.
Siehst du bei dir ja auch das da die Passwortabfrage kommt. Wenn es generell nicht gehen würde würde die fehlen.
Es kann sich also nur noch um ein Rechteproblem oder SMB Problem handeln.
Du musst aber drauf achten das es bei OS-X und auch MS eine Änderung der SMB / NetBios Versionen gegeben hat und das du da nicht in Inkompatibilitäten rennst. Da deine OS-X Version aber recht alt ist und NT ja auch entsprechendes auf dem Buckel hat ist das vermutlich noch Ver.1 auf beiden Seiten aber überprüfe das besser. Wie gesagt das gilt nur für Win CIFS Shares.
Beschrieben ist es z.B hier
http://www.windows-7-forum.net/windows-7-netzwerk-internet/6601-net-use ...
NTLM ver. 1
Dadurch das du es fehlerfrei Pingen kannst siehst du das die Netzwerk Connectivity fehlerlos funktioniert !
Du solltest also fehlerfrei auf Dienste unter OS-X von NT aus (VM) zugreifen können und auch umgekehrt von OS-X auf NT.
Das kannst du ganz einfach mal testen wenn du unter NT ein Terminalprog. Wie PuTTY installierst und eine SSH Session auf den OS-X Rechner 192.168.56.1 auchmachst.
Auch ein Mounting von SMB Shares auf OS-X müsste mit Start - Ausführen \\192.168.56.1\<name_verzeichnis problemlos möglich sein.
Siehst du bei dir ja auch das da die Passwortabfrage kommt. Wenn es generell nicht gehen würde würde die fehlen.
Es kann sich also nur noch um ein Rechteproblem oder SMB Problem handeln.
Du musst aber drauf achten das es bei OS-X und auch MS eine Änderung der SMB / NetBios Versionen gegeben hat und das du da nicht in Inkompatibilitäten rennst. Da deine OS-X Version aber recht alt ist und NT ja auch entsprechendes auf dem Buckel hat ist das vermutlich noch Ver.1 auf beiden Seiten aber überprüfe das besser. Wie gesagt das gilt nur für Win CIFS Shares.
Beschrieben ist es z.B hier
http://www.windows-7-forum.net/windows-7-netzwerk-internet/6601-net-use ...
NTLM ver. 1
Na ja die Fehlermeldungen von Winblows sind wie immer irreführend wie jeder weiss. Googel nach dem 53er dann siehst du das !
Das die User und Passwörter in beiden OS gleich sind stimmt de facto nicht, denn sonst würde die Passwort Abfrage nich hochpoppen !
Das es generll funktioniert kannst du ja klar der Tatsache entnehmen das es wie schreibst alles fehlerfrei mit XP klappt !
Fazit: es ist einzig und allein ein Problem von NT4 !
Check das mal mit der NTLM Version. Man kann das in der Windows Registry entsprechend anpassen, das ist kein Problem !
Das die User und Passwörter in beiden OS gleich sind stimmt de facto nicht, denn sonst würde die Passwort Abfrage nich hochpoppen !
Das es generll funktioniert kannst du ja klar der Tatsache entnehmen das es wie schreibst alles fehlerfrei mit XP klappt !
Fazit: es ist einzig und allein ein Problem von NT4 !
Check das mal mit der NTLM Version. Man kann das in der Windows Registry entsprechend anpassen, das ist kein Problem !
Der Mac nutzt ja Samba als CIFS Sharing Applikation wie alle unixoiden OS auch. Samba und auch Windows wurden über die Zeit umgestellt auf unterschiedliche NTLM Versionen so das es da zu einem Mismatsch kam. Speziell in der Zeit zu NT4 und XP, Win7 war das der Fall. Dann sind die NTLM Versionen zw. Samba und Windows nicht mehr kompatibel und das führt dann zu solch Authentisierungsfehlern.
Wie gesagt das ist mit einem kurzen Eingriff in die Windows registry gefixt. Macht maber nur Sinn wenn es dort wirklich einen Mismatch geben sollte.
Wie gesagt das ist mit einem kurzen Eingriff in die Windows registry gefixt. Macht maber nur Sinn wenn es dort wirklich einen Mismatch geben sollte.
NTLM ist nur das Authentisierungsverfahren und hat so mit SMB nichts zu tun. Es geht rein um das Authentisierungsverfahren beim Lan Manager...mehr nicht. Irgendwann ist auf NTLMv2 umgestellt worden bei Windows und die OS-X Samba Version ist erst später nachgezogen.
Im Zweifel musst du dir mal einen Wireshark nehmen auf dem Host oder VM und den CIFS Mounting Prozess mal mitsniffern und genau checken was da schiefläuft.
Generell funktioniert das fehlerfrei.
Im Zweifel musst du dir mal einen Wireshark nehmen auf dem Host oder VM und den CIFS Mounting Prozess mal mitsniffern und genau checken was da schiefläuft.
Generell funktioniert das fehlerfrei.
aber für die WIN NT für Workstation habe ich kein auf dem WIN NT Workstation OS gefunden.
Die XP Variante sollte da funktionieren. NT und XP nutzen den gleichen Kernel. Hast du mal versucht sie darauf zu installieren ?Der Systemfehler 53 bleibt.
Bei OS-X musst du auch nichts machen. Wenn dann geht das auch nur über das Terminal in den Samaba Settings.Vermutlich ist das aber auch nicht die NTLM Version, denn zu Zeiten von NT und XP funktionierte das immer fehlerlos mit älteren OS-X das es dort einzig nur NTLMv1 gab. das ist erst ab Win 7 auf v2 umgestellt worden.
Bei OS-X ist erst ab Lion oder Mountain Lion umgestellt worden auf v2.
Es ist eher zu vermuten das da was mit den Winblows Zugriffsrechten nicht stimmt....
Starte den Wireshark auf dem internen vNIC der beide Geräte koppelt und richte einen Capture Filter nur auf diese IPs ein damit du nicht den überflüssigen anderen Traffic siehst.
Dann startest du mit Start -> ausführen -> \\<ip_adress>\sharename einen Zugriff von NT4 auf den OS-X Share...oder umgekehrt unter OS-X mit Gehe zu -> Mit Server verbinden -> smb://<ip_adresse/sharename
und checkst mal ob der Wireshark dort irgendwelche Errors ausspuckt ?!
Dann startest du mit Start -> ausführen -> \\<ip_adress>\sharename einen Zugriff von NT4 auf den OS-X Share...oder umgekehrt unter OS-X mit Gehe zu -> Mit Server verbinden -> smb://<ip_adresse/sharename
und checkst mal ob der Wireshark dort irgendwelche Errors ausspuckt ?!