Der Gastgeber
Ich habe einen Host mit Ubuntu 12.04 unter 10.0.0.202. Er stellt eine NFS-Freigabe für andere Rechner im Netzwerk bereit. Hier ist der Inhalt von /etc/exports:
/media/storagedrive 10.0.0.0/24(rw,sync,no_subtree_check)
Die Absicht besteht hier darin, den Inhalt von /media/storagedrivemit anderen Maschinen im Netzwerk im IP-Bereich gemeinsam zu nutzen 10.0.0.0 - 10.0.0.255.
Arbeitender Kunde
Dies funktioniert einwandfrei mit einem Client-Rechner unter 10.0.0.40, auf dem Ubuntu 13.10 läuft, bekannt als MattDev. Dieser Rechner /etc/fstabsieht folgendermaßen aus:
UUID=8f8c838e-3ea2-457a-87f0-57b12dfab06c / ext4 errors=remount-ro 0 1
UUID=427089d4-46a2-432d-9df4-7016bdfc7df2 none swap sw 0 0
10.0.0.202:/media/storagedrive /mnt/NetworkStorageDrive nfs rsize=8192,wsize=8192,timeo=14,intr
Und ls -al /mnt/auf dieser Maschine sieht es so aus:
total 12K
drwxr-xr-x 3 root root 4.0K Feb 4 17:48 .
drwxr-xr-x 23 root root 4.0K Feb 5 08:44 ..
drwxrwxr-x 7 root plugdev 4.0K Feb 5 11:43 NetworkStorageDrive
Die Ausgabe idsieht folgendermaßen aus:
uid=1000(matt) gid=1000(matt) groups=1000(matt),4(adm),24(cdrom),27(sudo),30(dip),33(www-data),46(plugdev),112(lpadmin),124(sambashare)
Nicht funktionierender virtueller Client
Ich habe einen zweiten Client-Rechner, auf dem Ubuntu 12.10 läuft, als Gastbetriebssystem auf einem Windows 7-Host-Rechner. Der Host-Rechner ist im Netzwerk als 10.0.0.28. Der Gast-Rechner wird von Vagrant verwaltet, wobei VirtualBox 4.3.6 als Anbieter verwendet wird. Ich werde den Windows 7-Host AlexDevHost und den Ubuntu-Gast AlexDevGuest nennen.
Beim Ausführen showmount -e 10.0.0.202auf AlexDevGuest wird Folgendes erzeugt:
Export list for 10.0.0.202:
/media/storagedrive 10.0.0.0/24
Der Versuch, die Freigabe zu mounten, schlägt jedoch fehl:
$ sudo mount 10.0.0.202:/media/storagedrive /mnt/NetworkStorageDrive
mount.nfs: access denied by server while mounting 10.0.0.202:/media/storagedrive
Also begann ich, nach Problemen zu suchen:
$ ls -alh /mnt/
total 12K
drwxr-xr-x 3 root root 4.0K Feb 5 12:23 .
drwxr-xr-x 26 root root 4.0K Feb 5 12:23 ..
drwxr-xr-x 2 root root 4.0K Feb 5 12:23 NetworkStorageDrive
$ id
uid=1001(vagrant) gid=1001(vagrant) groups=1001(vagrant)
$
Diese UID und GID unterscheiden sich von dem Benutzer Matt auf MattDev. Also habe ich mit der UID für Vagrant herumgespielt, da ich gelesen habe, dass der NFS-Zugriff durch Abgleichen der IP-Adresse und der UIDs gesteuert wird. Also jetzt:
$ id
uid=1000(vagrant) gid=1001(vagrant) groups=1001(vagrant)
$ sudo mount 10.0.0.202:/media/storagedrive /mnt/NetworkStorageDrive
mount.nfs: access denied by server while mounting 10.0.0.202:/media/storagedrive
$
Immer noch kein Erfolg. Jetzt gehen mir die Ideen aus.
- Was mache ich falsch?
- Wenn der UID-Teil korrekt ist, kann ich dann irgendwie überprüfen, ob der NFS-Server-Computer meinen Zugriffsversuch als von stammend erkennt
10.0.0.28und nicht als von einer anderen IP, die nicht im zulässigen Bereich liegt?
Antwort1
Okay, ich habe es gelöst (oder zumindest habe ich es zum Laufen gebracht und ich glaube, ich weiß, woran es lag).
Ich habe das insecureFlag zur /etc/exportsZeile auf dem NFS-Server hinzugefügt, sodass es jetzt folgendermaßen aussieht:
/media/storagedrive 10.0.0.0/24(rw,sync,no_subtree_check,insecure)
Dieses Flag erlaubt Verbindungen von Client-Ports über IPPORT_RESERVED (1024).
Der Mount-Befehl funktioniert jetzt.
Ich vermute, dass das Fehlen des insecureFlags das Problem war, weil VirtualBox NAT verwendete, um die Anfrage an das physische Netzwerk weiterzuleiten. Der Port auf dem Ubuntu-Gast (AlexDevGuest) war also möglicherweise unter 1024, der übersetzte Port auf dem Windows 7-Host (AlexDevHost) war jedoch wahrscheinlich über 1024 und daher blockiert. Das Setzen des insecureFlags bedeutete jedoch, dass es erlaubt war.
Dieses Problem betrifft offensichtlich nicht die nicht-virtuelle Maschine MattDev.