IOW if you can't write to file on host, the guest can't either.Īfter setting up the file to be shared create a destination if you don't have one: Note that the host file permissions are transient. To share folders set them up to be shared. Share the clipboard (allowing you to copy and paste between host and guest).Ability to share files between host and guest.A guest that can run at native screen resolution.Having said that, I don't know what the 'right' solution to permissions mappings for Linux-on-Windows would be.+ , But I don't think it necessarily translates well when you've got a UNIX guest (i.e., Linux) running on Windows, given that NTFS has no concept of the execute *permission* and instead has its own idea of what it means for a file to be 'executable' (where the file name must end in.

I agree that this permissions mapping approach probably makes sense, and is by design, for UNIX-on-UNIX hosts/guests - e.g., a Linux guest on a Mac OS X host, and vice versa. bat files, since they are indeed only 'executable' on Windows. After all, on the Linux guest, it's not like you're going to be able to run those. However, I'm not convinced how practical this is. exe, etc.) into executable files (+x) on the Linux guest.

I understand why this is happening from a technical standpoint: basically, VBox's shared folders implementation is mapping what the Windows host considers to be 'executable' files (.bat. com files, and so on all show up with +x permissions on the Linux guest. Also, I've noticed that in 2.0.6, in a Linux guest running on a Windows host, the only files that _do_ show up as executable are those file types that are thought of as 'executables' on Windows itself.

Vbox shared folder permission