El montaje de carpeta compartida de Virtualbox desde fstab falla; funciona una vez que se completa el arranque

Tengo Ubuntu 13.10 instalado en Virtualbox 4.3. La máquina host es Windows.

Tengo un par de carpetas compartidas de Virtualbox montadas por / etc / fstab. Hasta hace poco, esta configuración funcionaba bien, pero después de actualizar Ubuntu 13.04 y Virtualbox 4.2 (esencialmente al mismo tiempo) el montaje de fstab dejó de funcionar. Me sale el siguiente error durante el arranque:

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

Presionar M para la recuperación manual y luego intentar montarlo manualmente también falla:

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

Pero si en cambio omito el montaje durante el arranque, espero a que se inicie Unity y luego lo monte manualmente en un shell, todo funciona bien:

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

Tenga en cuenta que cuando monto manualmente, dejo que mount tome todas las opciones de / etc / fstab, y funciona. Esto me sugiere que es algún tipo de problema de tiempo, donde Virtualbox no está "listo" para proporcionar los montajes de archivos compartidos en el punto / etc / fstab, los montajes se ejecutan durante el arranque.

Aquí está la línea fstab, solo para completar:

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

¿Hay algo que pueda hacer al respecto desde el lado de Ubuntu? ¿O alguien sabe más sobre esto desde el ángulo de Virtualbox?

Encontré un informe antiguo sobre el rastreador de errores de Virtualbox con síntomas idénticos, pero en ese caso el usuario había actualizado Virtualbox sin actualizar sus adiciones de invitados y resolver eso solucionó el problema; esto no está sucediendo aquí, definitivamente tengo las adiciones 4.3 instaladas.

También me encontré con este problema. Monto /var/wwwusando la funcionalidad de carpetas compartidas de VBox, por lo que esto fue bastante molesto.

La solución que encontré fue forzar la vboxsfcarga temprana del módulo, antes del montaje de los sistemas de archivos. Simplemente agregue vboxsfuna línea propia en /etc/modules.

Otra solución es configurar noauto /etc/fstaby montar unidades manualmente /etc/rc.local, pero esta no fue una buena solución para mí porque para ese momento Apache ya había comenzado y no había podido encontrar nada /var/www.

Además de la sugerencia de Richard Turner de agregar vboxsfuna línea propia /etc/modules, sugiero agregar la _netdevopción de montaje a /etc/fstab. Probé en Ubuntu 12.04 LTS y esto parece agregar la cantidad justa de retraso para que el montaje tenga éxito.

Mi /etc/fstabentrada:

dev /media/dev vboxsf defaults,_netdev 0 0

La solución de Richard dejó de funcionar para mí después de la última actualización (VirtualBox 4.3.18, Ubuntu 14.04). Afortunadamente pude arreglarlo, cargando vboxsfdirectamente con el kernel:

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

El primer comando agrega un parámetro para cargar el módulo al núcleo y el segundo actualiza el sistema de archivos init. Después de reiniciar pude volver a usar mis monturas fstab :)

Advertencia: el proceso de arranque podría congelarse si no se puede montar una carpeta compartida. Pruebe su configuración, antes de agregar el módulo a initramfs. Si su sistema se bloquea de todos modos, puede arrancar en modo de recuperación para solucionar el problema.

Solo quería decir que forzar la vboxsfcarga temprana del módulo me ayudó (como en la respuesta de Richard Turner), pero la línea fstab todavía no funcionó para mí.

Lo que terminé haciendo fue poner el comando de montaje (que funcionó) en /etc/rc.local. Un poco hack pero funcionó.

Con la carpeta compartida listada en fstab, encuentro que el arranque se bloqueará cuando intente montarlo usando VirtualBox 5 y Ubuntu 14.04. La solución parece ser retrasar el montaje hasta que el servicio GuestAddition esté disponible (la /etc/modulessolución de Richard Turner no me pareció suficiente).

Para hacerlo, asegúrese de tener noautolas opciones para la carpeta compartida en /etc/fstab. Por ejemplo, para una carpeta compartida llamada vmshare:

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

Luego agregue una línea para /etc/rc.localmontar el recurso compartido después del arranque:

mount vmshare

Parece que vboxsfcarece del fs-vboxsfalias (que es cómo los módulos del núcleo se cargan automáticamente al montar ese tipo de sistema de archivos por primera vez), por lo que agregar el alias /etc/modprobe.ddebería ser el truco:

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

Tuve el mismo problema y estaba trabajando en las soluciones sugeridas, pero sin éxito. La solución de Torben congeló la bota, por lo que tuvo que deshacerla. Entonces pensé que debería solucionar el /etc/fstabuso sudo mount -a. La sintaxis de mi entrada parecía perfecta, pero aun así falló. También pude montar manualmente el filesysten usando el comando mount en la ventana de terminal.

Lo que encontré es que tenía espacios entre los dos primeros parámetros (dispositivo y punto de montaje). Los reemplacé con una pestaña y funciona. ¡¡¡¡¿De Verdad?!!!!

Creo que he encontrado la manera correcta de lidiar con esto en Arch Wiki . comment=systemd.automountOpción de uso

La opción anterior va en el /etc/fstabarchivo con las otras opciones. Por ejemplo:

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