fstab files that work (YMMV)

Discussions about using Linux guests in VirtualBox.
Post Reply
Dan P
Posts: 36
Joined: 23. Dec 2019, 18:33

fstab files that work (YMMV)

Post by Dan P »

I know that it can be a major time consumer to work with fstab files. For this reason, I'm posting mine.. May help someone else out.

- This one will mount the shared drive no problem automatically into /media folder. Windows 10 is the host and there is a VirtBoxShared folder on the desktop.

- I unchecked in VirtualBox 'Shared Folder' settings - auto-mount.

- This is for ubuntu 20.04

- acl is invoked.

- fmask = 0111 makes all the files r/w. The directories are still set to executable... ha ha.

- YMMV - Your mileage may vary.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda5 during installation
UUID=038b0db4-fbca-4d63-a877-f7b26e4fc5e8 / ext4 errors=remount-ro,acl 0 1
# /boot/efi was on /dev/sda1 during installation
UUID=79B7-1D99 /boot/efi vfat umask=0077 0 2
/swapfile none swap sw 0 0

# fstab version of - sudo -H mount -t vboxsf VirtBoxShared /media -o fmask=0111 --rw
VirtBoxShared /media vboxsf uid=myuserid,gid=vboxsf,fmask=0111 0 0

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

:D
Dan P
Posts: 36
Joined: 23. Dec 2019, 18:33

Re: fstab files that work (YMMV)

Post by Dan P »

Original generic modification.

- Mount the shared drive no problem automatically into /media folder upon boot of Linux ubuntu guest.

- Windows 10 is the host and there is a VirtBoxShared folder on the desktop.

- I unchecked in VirtualBox 'Shared Folder' settings - auto-mount.

- This is for ubuntu 20.04

- YMMV - Your mileage may vary.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda5 during installation
UUID=038b0db4-fbca-4d63-a877-f7b26e4fc5e8 / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/sda1 during installation
UUID=79B7-1D99 /boot/efi vfat umask=0077 0 2
/swapfile none swap sw 0 0

# sudo -H mount -t vboxsf VirtBoxShared /media
# -This is the originally modified version. Works.
VirtBoxShared /media vboxsf defaults 0 0

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arQon
Posts: 231
Joined: 1. Jan 2017, 09:16
Primary OS: MS Windows 7
VBox Version: PUEL
Guest OSses: Ubuntu 16.04 x64, W7

Re: fstab files that work (YMMV)

Post by arQon »

I know that it can be a major time consumer to work with fstab files.
It can, but a few seconds of searching this forum would have found you plenty of examples, including ones that work reliably regardless of the host OS etc, which yours don't; or won't cause the VM to lock up if one of them fails; etc.

I do appreciate that you shared yours to "give back", which is welcome - but they're extremely limited in the scope of their correctness / function, and it might have been better to attach them to the end of any of the other threads on the subject as a "simplified case" rather than in isolation.

Still, it's well-intentioned, and now that there's a note here to remind anyone that it doesn't work for that there IS a search function and the topic has already been covered in more detail if they need it, I don't think anything else is needed. :)
Dan P
Posts: 36
Joined: 23. Dec 2019, 18:33

Re: fstab files that work (YMMV)

Post by Dan P »

Well that was all that I had/have in way of fstab files. I likely will not be posting any more to this thread.... Perhaps others will though.

Yes there are scatterings of fstab entries all over. For me, those solutions were not in intuitive locations. Why go all over the site, when good fstabs can all be in one thread? fstab as I mentioned is already a difficult subject to many... If this thread can gather all the ones that work as examples... it would only help the reader, IMO.

YMMV- The partition GUIDs in the fstab files will have to be changed .. but the basic structure is there.

arQon - if you know of these great fstabs... or anybody else... perhaps post them here(?)

If you post, include:
- Operating system / distro
- Host system (optional)
- A brief description of the feature of what the fstab does.
.
.
arQon
Posts: 231
Joined: 1. Jan 2017, 09:16
Primary OS: MS Windows 7
VBox Version: PUEL
Guest OSses: Ubuntu 16.04 x64, W7

Re: fstab files that work (YMMV)

Post by arQon »

The short version is that fstab is often a poor way to mount vbox filesystems in the first place. (It used to be okay, but has constistenly become more problematic over the years for reasons that escape me, though most of that was a tangled mess causing the vbox driver to not be available at boot time, IIRC). These days I overwhelmingly prefer to use /etc/rc.local for it instead, which (usually) avoids most of those problems by being late enough in the boot process that all the various pieces have gotten their act together by the time the system gets that far. :)

If it's working this month, on this vbox release, guest, and etc, great. But after years of random intermittent issues, I just don't bother any more. It's also a REALLY bad idea if you ever use that VM on a different host, where some of those mounts may not exist. If they're in rc.local, they fail immediately and life goes on. If they're in fstab though, and you miss the noauto/nowait/etc on them, you can end up with a guest that hangs at boot and may not be recoverable even at runlevel 1.

re "The directories are still set to executable..." - the x bit on directories actually means *traversable* rather than executable. If you do filter it out, you'll run into all sorts of oddness like not actually being able to get a listing of the directory even if it has read permission. (And if you have certain types of symlinks somewhere under there, those can break in even more confusing ways).

Some other quick notes:

fmode=666 is more comprehensible to most people than the inversion of it to fmask=111 is.

Guests that you also want usable on *nix hosts need to be mounted with "uid=1000,gid=1000" (or etc), or, again, Weird Things that you don't want will happen, like not being able to update timestamps on files *even though the files are writable*, which is a major problem for utilities like rsync, as well as your sanity. :P

HTH
Post Reply