Podłączenie folderu współdzielonego Virtualbox z fstab kończy się niepowodzeniem; działa po zakończeniu rozruchu

Mam Ubuntu 13.10 zainstalowany w Virtualbox 4.3. Komputer hosta to system Windows.

Mam kilka folderów współdzielonych Virtualbox montowanych przez / etc / fstab. Do niedawna ta konfiguracja działała dobrze, ale po aktualizacji z Ubuntu 13.04 i Virtualbox 4.2 (w zasadzie w tym samym czasie) montowanie fstab przestało działać. Podczas uruchamiania pojawia się następujący błąd:

An error occurred while mounting /home/benme/Documents.
keys:Press S to skip mounting or M for manual recovery

Naciśnięcie M w celu ręcznego przywrócenia, a następnie próba ręcznego zamontowania również kończy się niepowodzeniem:

root@benme-vb:~# cd /home/benme
root@benme-vb:/home/benme# mount Documents
/sbin/mount.vboxsf: mounting failed with the error: No such device

Ale jeśli zamiast tego pomiń montowanie podczas uruchamiania, poczekaj na uruchomienie Unity, a następnie podłącz ręcznie w powłoce, wszystko działa dobrze:

benme-vb ~ % ls Documents
benme-vb ~ % sudo mount Documents
[sudo] password for benme: 
benme-vb ~ % ls Documents
    # actual file list omitted

Zauważ, że kiedy montuję ręcznie, pozwalam montować wziąć wszystkie opcje z / etc / fstab i to działa. To sugeruje mi, że jest to jakiś problem z timingiem, w którym Virtualbox nie jest „gotowy” do zapewnienia udostępnionych montowań plików w punkcie / etc / fstab uruchamianym podczas uruchamiania.

Oto linia fstab, tylko dla kompletności:

Documents       /home/benme/Documents   vboxsf  uid=benme,gid=benme,dmode=774,fmode=664     0   0

Czy mogę coś z tym zrobić od strony Ubuntu? A może ktoś wie o tym więcej z perspektywy Virtualbox?

Znalazłem stary raport na temat śledzenia błędów Virtualbox z identycznymi objawami, ale w tym przypadku użytkownik zaktualizował Virtualbox bez aktualizacji swoich dodatków gości i rozwiązania tego problemu; to się nie dzieje tutaj, zdecydowanie mam zainstalowane dodatki dla gości 4.3.

Wystąpił też problem tego problemu. Zamontować /var/wwwza pomocą VBox wspólne działanie folderów, więc było to dość uciążliwe.

Rozwiązaniem, które znalazłem, było wymuszenie vboxsfwczesnego ładowania modułu, przed zamontowaniem systemów plików. Po prostu dodaj vboxsfwłasną linię /etc/modules.

Innym rozwiązaniem jest ustawienie noauto /etc/fstabi ręczne zamontowanie dysków /etc/rc.local, ale nie było to dla mnie tak dobre rozwiązanie, ponieważ do tego czasu Apache już się uruchomił i nie mógł nic znaleźć /var/www.

Oprócz sugestii Richarda Turnera, aby dodać vboxsfwłasną linię /etc/modules, sugeruję dodanie _netdevopcji mount do /etc/fstab. Testowałem na Ubuntu 12.04 LTS i wydaje się, że dodaje to odpowiednią ilość opóźnienia, aby mount mógł się powieść.

Mój /etc/fstabwpis:

dev /media/dev vboxsf defaults,_netdev 0 0

Poprawka Richarda przestała działać dla mnie po ostatniej aktualizacji (VirtualBox 4.3.18, Ubuntu 14.04). Na szczęście udało mi się to naprawić, ładując się vboxsfbezpośrednio z jądrem:

# echo "vboxsf" >> /etc/initramfs-tools/modules
# update-initramfs -u

Pierwsze polecenie dodaje parametr, aby załadować moduł do jądra, a drugie aktualizuje system plików init. Po ponownym uruchomieniu mogłem ponownie użyć moich mocowań fstab :)

Ostrzeżenie: Proces rozruchu może się zawiesić, jeśli nie można zamontować folderu współdzielonego. Więc przetestuj swoją konfigurację, zanim dodasz moduł do initramfs. Jeśli mimo to system się zawiesi, możesz uruchomić system w trybie odzyskiwania, aby rozwiązać problem.

Chciałem tylko powiedzieć, że wymuszenie vboxsfwczesnego ładowania modułu pomogło mi (tak jak w odpowiedzi Richarda Turnera), ale linia fstab nadal nie działała dla mnie.

Skończyło się na tym, że umieściłem polecenie mount (które zadziałało) /etc/rc.local. Trochę hack, ale zadziałało.

Z folderu współdzielonego wymienionego w fstab widzę, że boot się zawiesi, gdy spróbuje go zamontować za pomocą VirtualBox 5 i Ubuntu 14.04. Wydaje się, że rozwiązaniem jest opóźnienie montażu, dopóki usługa GuestAddition nie będzie dostępna ( /etc/modulesrozwiązanie Richarda Turnera nie wydawało mi się wystarczające).

Aby to zrobić, upewnij się, że masz noautojako opcje udostępnionego folderu w /etc/fstab. Na przykład dla udostępnionego folderu o nazwie vmshare:

vmshare    /home/user/share    vboxsf    defaults,noauto    0    0

Następnie dodaj wiersz, /etc/rc.localaby zamontować udział po uruchomieniu:

mount vmshare

Wygląda na to, że vboxsfbrakuje fs-vboxsfaliasu (tak właśnie moduły jądra są ładowane automatycznie podczas montowania tego typu systemu plików po raz pierwszy), więc dodanie aliasu /etc/modprobe.dpowinno załatwić sprawę:

$ echo "alias fs-vboxsf vboxsf" | sudo tee /etc/modprobe.d/vboxsf.conf

Miałem ten sam problem i pracowałem nad sugerowanymi rozwiązaniami, ale bez powodzenia. Rozwiązanie Torbena zamroziło bagażnik, więc musiał je cofnąć. Wtedy pomyślałem, że powinienem rozwiązać problem z /etc/fstabużywaniem sudo mount -a. Składnia mojego wpisu wyglądała idealnie, ale i tak się nie udało. Byłem także w stanie ręcznie zamontować plik fileysten za pomocą polecenia mount w oknie terminala.

Odkryłem, że mam spacje między dwoma pierwszymi parametrami (urządzeniem i punktem montowania). Zastąpiłem je kartą i działa. Naprawdę?!!!!

Myślę, że znalazłem właściwy sposób, aby sobie z tym poradzić w Arch Wiki . Użyj comment=systemd.automountopcji.

Powyższa opcja wchodzi do /etc/fstabpliku z innymi opcjami. Na przykład:

Fedora /var/ftp/pub/Fedora vboxsf uid=1001,gid=1001,comment=systemd.automount 0 0