Incorrect Options listed in /etc/fstab for Shared Folder Mount entry for vmhgfs-fuse causes Debian to crash on boot

[Shawn1357]

Describe the bug

Windows 10 Host VMWare Workstation Pro 16.1.2 build-17966106 Debian 12 Guest with Gnome Desktop (with inactive root account) Open VM Tools: 2.12.2.0-1+deb12u2 amd64

Followed instructions in:

• https://docs.vmware.com/en/VMware-Workstation-Pro/16.0/com.vmware.ws.using.doc/GUID-D6D9A5FD-7F5F-4C95-AFAB-EDE9335F5562.html
• fstab Method 2 of https://kb.vmware.com/s/article/60262

Reproduction steps

1. Create a directory on the host to be shared with a virtual machine such as D:\TEMP\Debian-Test

2. Populate that host directory with at least one file.

3. Create a vanilla VMWare guest installation of Debian 12. (Likely the problem can be replicated in any existing Debian guest - or even other Linux flavors)

4. Create a mount point directory in the virtual machine (such as /mnt/hgfs/debian-tst)

5. Enable and create a Shared Folder in the Virtual Machine Settings: For example: Host Dir: D:\TEMP\Debian-Test, Name: debian-test, Enabled

6. Create a valid /etc/fstab entry such as: .host:/debian-test /mnt/hgfs/debian-tst fuse.vmhgfs-fuse defaults,allow-other 0 0

7. Reboot machine and validate mount point works.

8. Take a snapshot of the virtual machine so you can recover from bricking it in the next step.

9. Modify the fstab entry to contain an invalid option such as adding "ttl=5" to the options: .host:/debian-test /mnt/hgfs/debian-tst fuse.vmhgfs-fuse defaults,ttl=5,allow-other 0 0

10. Reboot and virtual machine crashes on boot. ...

Expected behavior

At the very minimum, the boot process should be able to continue, perhaps in an emergency mode, to a point where a shell is possible. Preferably, the boot should continue with out that specific fstab entry being mounted and appropriate errors logged somewhere.

Additional context

I have not tried this process with the 'root' account being active.

I am unable to review system logs because the system does not allow me to get to a shell to examine them.

Screen Boot Log indicating crash - this crash effectively bricks the guest machine as far as I can tell:

Pressing Enter results in a seemingly endless cycle of attempting to launch a console but 'root' is not active.

[Shawn1357]

If instead of rebooting in Step 10, I issue the command 'mount -a': `mount -a

fuse: unknown option(s): '-o ttl=5' mount: (hint) your fstab has been modified, but systemd still uses the old version; use 'systemctl daemon-reload' to reload. `

This seems a clean reaction to the problem. However, a reboot at this point exhibits the same boot crash.

[vmwkruti1111]

Hi Shawn, Incase your root account is locked (or inactive), you can try passing ",nofail" to the fstab entry for the shared folder to continue boot process even if drive fails to mount due to unknown option.

.host:/debian-test /mnt/hgfs/debian-tst fuse.vmhgfs-fuse defaults,ttl=5,allow-other,nofail 0 0

Thanks

[lousybrit]

We will update the mentioned https://kb.vmware.com/s/article/60262 article. Thanks!

[Shawn1357]

Hi Shawn, Incase your root account is locked (or inactive), you can try passing ",nofail" to the fstab entry for the shared folder to continue boot process even if drive fails to mount due to unknown option.

Thanks for the work-around and it indeed works.

However, in my case the work-around is too late - root is not enabled. The machine is effectively bricked because it will not boot beyond Press Enter to Continue prompt during the boot process (because the root account is not enabled). I suppose it might be possible to boot from a Live Distribution ISO and recover that way but I would argue that the effect of this problem is too severe: entering "allow-other" rather than the correct "allow_other" option effectively renders the virtual machine unusable.

If "nofail" is going to be the suggested work-around (and it does exhibit, in my head at least, an acceptable response), shouldn't "nofail" then be the default behavior unless otherwise stated in the list of options?