virtualbox.org

Greetings all,

I'm running an Ubuntu 8.04 AMD64 guest on a Vista 64-bit machine. I've set up a VBox shared folder (r/w) on my Vista host so that I can write files to my Windows file system from my Ubuntu guest. Specifically though, sometimes I need to do a "chmod +x" on those files on the shared folder so that they become executable / i.e., so that I can run those files (from my Vista file system) on my Ubuntu guest. Namely, I want to create executable binaries and shell scripts in Ubuntu (that are hosted on the Vista FS).

It was my understanding that when I run "mount.vboxsf" on my Ubuntu guest to mount the Vista shared folder, the vboxsf mount option "fmode" should allow me to do this. e.g., I'd have thought I could specify "-o fmode=755" as a vboxsf mount option.

But no matter what I try, this doesn't work. Regular files are never mounted as, nor can be changed to be, executable. Though, strangely, any file with a DOS extension -- like .bat, .exe, .cmd, .com, and so on -- *is* automatically mounted or created with the execute bit turned on!

So my question is: Does the mount.vboxsf "fmode" option, or even the "dmode" option for that matter, even work? Are these options even implemented? As far as I can tell, they don't do anything.

Thanks for your time...

It was listed as mount options a few versions ago (I think 2.0). Check the manual to see what is available.

Sasquatch wrote:It was listed as mount options a few versions ago (I think 2.0). Check the manual to see what is available.

Heh, yeah, the manual doesn't even mention any options other than uid, gid, and umask. I only found out about the fmode and dmode options (and fmask and dmask) by deliberating feeding some invalid options into mount.vboxsf to get syntax help. At that point, syntax help listed a bunch of options that aren't mentioned in the manual.

But I just can't see that fmode and dmode actually work / are implemented. Using them seems to have no effect on the mode of files/dirs that are mounted from a Windows shared folder.

Well, looks like I'm not alone. Searching the forums reveals that lots of other people are having similar problems -- and not just on a Windows host as I did, but also on Mac OS X hosts, and so on.

This may be a relevant bug (though it was originally opened for a Mac host): http://www.virtualbox.org/ticket/1776

Moreover, the VBox 2.0.6 manual's section on Shared Folders mentions the use of "generic" mount options like uid, gid, and mode. But what's "mode"? "mode" doesn't exist as a generic mount option. _Some_ file system mount types support similarly named "fmode" and "dmode" options -- but there's no generic "mode" option supported by mount. So is this a typo in the manual?

As far as I can tell, and from reading all the other related posts in these forums, setting permissions on shared folders from within a Linux guest seems fairly busted as of 2.0.6.

IIRC fmode and dmode do work at least for Linux and MacOS hosts. mode doesn't and throws an error. The manual is wrong.

FYI, I'm now pretty sure that, based on the current status of http://www.virtualbox.org/ticket/1776, the problems with the inability to set the execute bit for files in a Linux guest running on a _Windows_ host are still outstanding -- even in VBox 2.0.6 (what I'm running).

That is, it's possible that the original reported problem on the Mac OS X host may be gone, but the problem still exists on a Windows host. It seems that there's no way out-of-the-(virtual)-box (ha!) to do a chmod +x on existing or new files in the shared folder from the Linux guest (if the host is Windows). None of the fmode, dmode, fmask, dmask, umask, or exec options seem to work in Linux when the host is Windows.

Fortunately, in http://www.virtualbox.org/ticket/1776, "ejtttje" has posted a workaround that involves changing a line of code in the VBox guest additions module and (re-)compiling it. Also see http://forums.virtualbox.org/viewtopic.php?t=6691. The recompile turns _all_ files into executables (for the user) on the Linux guest, which is effectively what I was trying to do earlier with the fmask option. I've found that this works for an Ubuntu 8.04.1 AMD64 guest when running on a Vista x64 SP1 host.

That may be a good enough solution (that is, workaround) for now until the VBox devs figure out a more formal fix for Windows hosts.