vmware / open-vm-tools

Official repository of VMware open-vm-tools project
http://sourceforge.net/projects/open-vm-tools/
2.24k stars 426 forks source link

Windows host Shared Folders to Linux guest wrong permissions #334

Open hydrajump opened 5 years ago

hydrajump commented 5 years ago

I'm running VMware Workstation 15 on Windows 10 and my guest is Debian 9 VM. When I share folders from the host to the VM using the following:

$ sudo /usr/bin/vmhgfs-fuse .host:/ /mnt/hgfs -o subtype=vmhgfs-fuse,allow_other,uid=1000,gid=1000,umask=0033

The directory and file permissions look like this:

-rwxr--r-- 1 testuser testuser 57 Apr 23 10:00 testfile
drwxr--r-- 1 testuser testuser 0 Mar 12 11:00 testdir

If I create directories or files on the Linux VM the permissions look like this:

-rw-r--r-- 1 testuser testuser 57 Apr 23 10:00 testfile
drwxr-xr-x 1 testuser testuser 0 Mar 12 11:00 testdir

I've tried different umask options when I mount the vmhgfs-fuse fs, and I can't get the permissions to be the same as when I create files directly on the Linx VM.

Is this a bug or do I manually have to change permissions on the files that I copy from host to VM?

lousybrit commented 5 years ago

Hello,

Thanks for reporting this issue.

This is expected behavior with the current implementation, as the Windows server does not attempt to map group or world permissions. This has been that way for an awfully long time. Having said that, I will check to see if we can improve it so that it is more consistent with the default behavior of the Linux server and host.

Steve

ibuetler commented 4 years ago

Any news on that?

Ivan

lousybrit commented 4 years ago

Unfortunately, no updates on this issue as our Beijing team that now owns this feature have been focusing on file copying performance. So I would hope that there will be some notable differences with newer releases in this regard.

I am filing a bug for this particular issue. However, you expand on your particular usage to explain why the user permissions cause an issue? Reason is that this has been like this for years but not seen any requests to modify the behavior until this one. It will help raise the priority of the bug.

Thanks.

Steve