VMware shared folders rely on the vmhgfs-fuse driver, which restricts visibility to the mounting user by default. To make files created in the guest visible to the host or other users, you must explicitly enable the allow_other option during the mount process. This setting relaxes the strict user namespace isolation that VMware enforces for security reasons.
Understanding the Visibility Restriction
When you configure a shared folder in VMware Workstation or Player, the virtual machine mounts this directory using a FUSE (Filesystem in Userspace) driver calledvmhgfs-fuse. Unlike traditional network file systems such as NFS or SMB, this driver operates within the context of the specific user who initiated the mount command. By design, this ensures that only the user running the mount can see and interact with the files. If a different user, or the root user acting on behalf of a service, creates a file, it may remain invisible to others unless specific permissions are granted.
This behavior is often mistaken for a permission error or a bug in the hypervisor. However, it is a deliberate security feature intended to prevent unauthorized access to host resources from within the guest operating system. The issue typically manifests when scripts or background processes running under one user account create files that another user account cannot read or list. For example, if you run a build script as sudo but try to view the output as your standard user, the files will appear missing because they were created in a restricted context.
Configuring allow_other for Visibility
The primary solution involves modifying the mount options to includeallow_other. This flag tells the vmhgfs-fuse driver to allow access to the shared folder for all users, not just the one who mounted it. You should avoid attempting to manage this through complex ACLs or by altering the global UID mapping of the VM, as these methods are unnecessary and can break other functionality. Instead, focus on the mount parameters themselves.
If you are using the graphical interface in VMware Workstation, ensure that the shared folder is enabled and then check the manual mount instructions provided in the documentation. For most Linux guests, the automatic mount occurs at /mnt/hgfs. You can verify the current mount options by running the mount | grep vmhgfs command. If allow_other is absent, you will need to remount the filesystem with the correct flags.
To manually mount the shared folder with the necessary permissions, use the following command structure:
sudo vmhgfs-fuse .host:/ /mnt/hgfs -o allow_otherchown if they were previously created with restrictive permissions that block reading even after enabling allow_other.
Mounting VMware Shared Folder in Linux Guest provides additional context on default paths and automation scripts that might help you integrate this mount command into your startup sequence.
Automating the Mount Options
For persistent solutions, especially in server environments or automated workflows, hardcoding manual mount commands is inefficient. You can configure the system to automatically applyallow_other every time the virtual machine boots. One robust method is to create a systemd service unit that handles the mounting process after the network stack is initialized.
Create a file named /etc/systemd/system/vmware-hgfs.service with the following content:
[Unit]
Description=Mount VMware Shared Folders
After=network.target
[Service]
Type=oneshot
ExecStart=/usr/bin/vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other
[Install]
WantedBy=multi-user.targetsystemctl enable vmware-hgfs.service. This approach ensures that the shared folder is mounted with the correct permissions regardless of which user logs in first. It also decouples the mounting logic from the user session, preventing issues where a user logs in before the shared folder is ready.
Another alternative is to modify the /etc/fstab file, although support for FUSE filesystems in fstab varies by distribution. If your distribution supports it, you can add an entry like:
.host:/ /mnt/hgfs fuse.vmhgfs-fuse allow_other 0 0Troubleshooting Permission Denials
Even withallow_other enabled, you might encounter "Permission Denied" errors if the underlying file permissions on the host side are restrictive. Remember that the guest OS sees the files with the permissions defined on the host. If a file is created with mode 0600 on the host, it will likely remain unreadable by other users in the guest, even if the mount allows access. Ensure that the files on the host machine have appropriate read/write permissions for the intended audience.
Additionally, verify that the open-vm-tools package is installed and running in your Linux guest. This package provides the essential drivers and utilities for VMware integration, including the vmhgfs-fuse binary. Without it, the shared folder feature will not function correctly. You can install it via your package manager, such as apt install open-vm-tools-desktop for Ubuntu-based systems.
os.OpenFile threw "permission denied" on a file that has mode 0666 discusses similar permission conflicts that can arise in file handling scenarios, offering insights into how permission modes interact with access controls.
Security Considerations
Enablingallow_other reduces the security boundary between the guest and the host. While it is convenient for development and testing, it exposes all shared files to every user account within the virtual machine. In a multi-user environment, this could allow a malicious or compromised user to read sensitive data from the host. Use this setting only when necessary and consider restricting access through firewall rules or user group permissions if security is a concern.
For production environments, it is often better to map specific users to specific shared folders or use SSH/SFTP for file transfers instead of relying on persistent shared folders. This approach provides granular control over who can access what data without compromising the integrity of the entire shared directory structure.
Frequently Asked Questions
Why do I see empty folders in /mnt/hgfs?
This usually indicates that the vmhgfs-fuse driver is mounted but lacks the allow_other permission, causing it to hide files created by other users. Remounting with the -o allow_other flag typically resolves this visibility issue immediately.
Can I use NFS instead of VMware shared folders?
Yes, setting up an NFS server on the host or another machine can provide more flexible permission controls and better performance for large file transfers. However, it requires additional network configuration and does not offer the seamless integration that VMware's native shared folder feature provides.
Does allow_other affect host security?
It primarily affects guest-side access control, allowing any user in the VM to see the shared files. It does not grant the guest write access to the host filesystem beyond what is configured in the VMware settings, but it does reduce isolation between guest users regarding those specific files.
How do I remove a shared folder from the guest?
You can unmount the filesystem using the umount /mnt/hgfs command. To permanently remove the folder, edit the VM settings in VMware Workstation and delete the shared folder entry from the list of configured shares.
What if my guest OS is Windows?
Windows guests handle shared folders differently, using a mapped network drive (typically Z:) rather than a FUSE mount. Visibility issues in Windows are usually related to credential caching or group policy restrictions rather than mount options like allow_other.