No execute permission on file in shared folder, Mac host, Linux guest

[Paul]

Virtualbox 1.6.2 on MacOSX. The guest is Linux (Ubuntu, hardy heron). In a shared folder, I created hello.c. On the guest, I compiled it, but the execute permission is missing:

   vbox:/mac$ gcc hello.c
   vbox:/mac$ ls -l                                                     
   -rw------- 1  6362 2008-06-18 10:26 a.out
   -rw------- 1    79 2008-06-18 10:13 hello.c                   

Manually setting the x bit does not work:

   vbox:/mac$ chmod +x a.out                                            
                                                                              
   vbox:/mac$ ls -l                                                     
   -rw------- 1  6362 2008-06-18 10:26 a.out
   -rw------- 1    79 2008-06-18 10:13 hello.c                   

However, running the "chmod +x a.out" on the mac does properly change the mode and allows the guest to run the binary:

   vbox:/mac$ ls -l                                                     
   -rwx--x--x 1  6362 2008-06-18 10:26 a.out
   -rw------- 1    79 2008-06-18 10:13 hello.c                   
                                                                              
   vbox:/mac$ ./a.out                                                   
   Hello from C                   

[Dave Korn]

Replying to frank:

Those new host/guest settings are unduly restrictive. I can reproduce the exact same problem on a windows XP host with an ubuntu guest.

[Dave Korn]

Replying to Paul:

Virtualbox 1.6.2 on MacOSX.

VB 1.6.0 on WinXp here. Same problem.

The guest is Linux (Ubuntu, hardy heron).

Same guest.

In a shared folder, I created hello.c. On the guest, I compiled it, but the execute permission is missing:

Exact same here, but there's no way to set the execute perm even from the host side. I made sure the ACL for the directory gave full control to the "Everyone" user, no difference; I checked the ACL for the generated a.out itself, it had correctly inherited full control for everyone, still couldn't be executed from the guest side.

Just in case, I tried unmounting the shared folder and remounting it with the 'exec' option. Still no luck.

[Ethan Tira-Thompson]

I agree the 'host' field is overly restrictive, this is a more general problem. For windows, vboxfs probably needs to support fmask or umask so files can be executable by default. For OS X, vboxfs should allow upstream modification of the flags on the host. I expect this problem also exist on Linux hosts.

[Ethan Tira-Thompson]

As an ugly workaround, I have edited the vboxvfs kernel module (the joys of open source! Otherwise I'd be screwed on monday! :)

How to:

1. mount the VBoxGuestAdditions.iso (e.g. /media/cdrom0)
   
2. mkdir vbox && cd vbox && /media/cdrom0/VBoxLinuxAdditions.run --tar -xf
   
3. edit module/vboxvfs/utils.c, change line 96 "mode |= mode_set (IXUSR);" to "mode |= S_IXUSR;"

(note addition of "S_" prefix... basically, always set executable flag)

4. sudo ./install.sh vfs-module
   
5. cd .. && rm -rf vbox

This sets the executable flag in the guest only (mode 700) for all shared files — the host still always gets mode 500 for newly created files. Hopefully a dev can make a proper fix. (slight improvement: set executable on new file creation, and keep file permissions in sync otherwise so non-executables in the host don't show up as executable in the guest)

But at least this lets me do development within a shared directory...

[Dave Korn]

ejtttje, thanks a million! I have tested your fix on my setup and it works for me too. You saved me hours of grepping through the sources, I wouldn't even have known whether to look at the host or guest end of things to start with! I owe you virtual beer, cheers!

[Mjalik Anton]

Virtualbox 1.6.2 on WinXP. The guest is Linux (Kubuntu, hardy). After this:

Replying to ejtttje:

How to:

1. mount the VBoxGuestAdditions.iso (e.g. /media/cdrom0)
   
2. mkdir vbox && cd vbox && /media/cdrom0/VBoxLinuxAdditions.run --tar -xf
   
3. edit module/vboxvfs/utils.c, change line 96 "mode |= mode_set (IXUSR);" to "mode |= S_IXUSR;"

(note addition of "S_" prefix... basically, always set executable flag)

4. sudo ./install.sh vfs-module
   
5. cd .. && rm -rf vbox

Installation ends with error:

/tmp/vbox.l/utils.c:96: error: 'RTFX_UNIX_S_USER' undeclared (first use in this function)

/tmp/vbox.l/utils.c:96: error: (Each undeclared identifer is reported only once

/tmp/vbox.l/utils.c:96: error: for each function it appears in.)

/tmp/vbox.l/utils.c:96: error: 'S_S_IXUSR' undeclared (first use in this function)

[Mjalik Anton]

Oh, sorry, my bad. I have done mistake. Instead of "mode |= S_IXUSR;" I entered "mode |= mode_set (S_IXUSR);". All works fine.

[Frank Mehnert]

Starting with 1.6.6 there will be some additional filesystem options which can be specified when mounting a shared folder into a Linux guest:

• umask will specify all bits which should be cleared for every file/directory
• dmask same as umask for directories only
• fmask same as umask for regular files only
• dmode will specify the mode for every directory in the shared folder
• fmode same as dmode for regular files.

So specifying

mount -t vboxsf -o fmode=555

will make every file have r+x bits set. Note that the vboxvfs kernel module still ignores read/write permissions of the files, that is, if the file is readable by the on the host the file will be readable on the guest as well, same for write, regardless of the file permissions inside the guest.

[Tim K.]

The fix listed (using -o arguments) does not solve the issue on my system:

Windows Vista Ultimate 32-bit Host GNULinux Ubuntu 8.1 32-bit guest

Able to mount a shared folder, but unable to run compiled C++ compiled binary executables within the code directory. ls -l Reports no exec permissions granted, regardless of options used during mount. Directory mounted has full permissions on Windows machine. Unable to add exec permissions to any user (including root).

[Tim K.]

Also, VB version 2.0.4.

[Titantux]

The workaround by "ejtttje" it is working for VB version 2.0.4 as well. I did it on Ubuntu 8.10 guest, Vista Prof host.

[Tim K.]

My third attempt at a fix was using ejtttje's workaround. However, the GNULinux guest additions installation failed at the file system build, with errors similar to the ones posted by Mjalik. I am changing the correct line to what was described as the fix, but this does not suppress the error (neither the "incorrect" or "corrected" posts by ejtttje)

[Titantux]

I had a problem like... Unable to build the kernel module. See the log file /var/log/vboxadd-install.log... but was when I left the line as following:

mode |= mode_set (S_IXUSR);

But, when I just left as below, it works...

mode |= S_IXUSR;

[Tim K.]

I apologize for not posting my solution earlier, but Titantux is correct, I reached the same conclusion through trial and error a little while ago.

[Frank Mehnert]

Replying to XBigTK13X:

The fix listed (using -o arguments) does not solve the issue on my system:

Windows Vista Ultimate 32-bit Host GNULinux Ubuntu 8.1 32-bit guest

Actually this works fine here. Vista Ulimate host, Debian guest (both 32-bit). Are you sure that you updated the guest additions? What happens if you create a file on that share, does it have exec permissions?

[Tim K.]

Ubuntu guest for me, but shouldn't make a difference. The mount script prior to editing the file system module had the proper switches for mounting with exec permission, but execution was still not possible.

[Frank Mehnert]

Does anybody else have this problem with VirtualBox 2.0.4?

[Paulo]

I'm not sure if what's happpening to me is the same issue you are talk about here, sorry if not. I work on a Ubuntu host, XP guest. Whenever I edit or create a file on the XP guest, it looses its execution permisions. I'm just scripting php on Dreamweaver against Ubuntu's apache, but it's werd to change file permisions every time I save a file on XP guest. Well, not only werd, it's imposible to work this way. And yes, I'm on 2.0.4 version.

[edwinhu]

I can confirm this problem still exists as of version 2.0.4. I'm on XP host with ubuntu guest, Either the ejtttje or frank's fix did not work.

[oogabooga2000]

Replying to marspathfinder:

I can confirm this problem still exists as of version 2.0.4. I'm on XP host with ubuntu guest, Either the ejtttje or frank's fix did not work.

I can also confirm that this problem continues to exist in VBox 2.0.6 on a Vista x64 SP1 host running an Ubuntu 8.04.1 AMD guest. Though for me, ejtttje's workaround (involving the module recompile) _does_ work.

[oogabooga2000]

In fact, as far as I can tell, the fmode, dmode, fmask, dmask, and umask options for mount.vboxsf don't work at all (that is, they don't do anything) on Linux when the host is Windows.

Moreover, the 2.0.6 manual's section on Shared Folders mentions the use of the 'uid', 'gid', and 'mode' options, which are all supposedly "generic" to mount. But what is "mode"? It's certainly not generic to the mount command. I can't find _any_ -t file system types that accept a "mode" option. "fmode" and "dmode" are close matches, of course.

So I think that the use of the non-existent "mode" mount option must be a typo in the VBox manual.

[edwinhu]

Thanks for the message! I removed the existing share folder, tried it again and now it gives me 700 access, I'm not sure why I failed last time but now it works!

Also thanks to ejtttje for the great fix!

Replying to oogabooga2000:

Replying to marspathfinder:

I can confirm this problem still exists as of version 2.0.4. I'm on XP host with ubuntu guest, Either the ejtttje or frank's fix did not work.

I can also confirm that this problem continues to exist in VBox 2.0.6 on a Vista x64 SP1 host running an Ubuntu 8.04.1 AMD guest. Though for me, ejtttje's workaround (involving the module recompile) _does_ work.

[Frank Mehnert]

Replying to oogabooga2000:

In fact, as far as I can tell, the fmode, dmode, fmask, dmask, and umask options for mount.vboxsf don't work at all (that is, they don't do anything) on Linux when the host is Windows.

It turned out that there was a bug preventing the usage of the new options. See r14598.

Moreover, the 2.0.6 manual's section on Shared Folders mentions the use of the 'uid', 'gid', and 'mode' options, which are all supposedly "generic" to mount.

Correct, there is no mode option, only fmode and dmode are supposed to work.

Thanks for the report.

[oogabooga2000]

In fact, as far as I can tell, the fmode, dmode, fmask, dmask, and umask options for mount.vboxsf don't work at all (that is, they don't do anything) on Linux when the host is Windows.

It turned out that there was a bug preventing the usage of the new options. See r14598.

Thanks for digging into this, frank.

Any idea if the fix (to allow the new options to work) will make it into 2.0.8?

[oogabooga2000]

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. e.g., .cmd and .bat files (that is, batch scripts), .exe files, old .com files, and so on all show up with +x permissions 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, .exe, etc.) into executable files (+x) on the Linux guest. However, I'm not convinced how practical this is. After all, on the Linux guest, it's not like you're going to be able to run those .exe or .bat files, since they are indeed only "executable" on Windows.

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. 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 .exe, .bat, or whatever).

Having said that, I don't know what the "right" solution to permissions mappings for Linux-on-Windows would be. :)

[Johan Lundberg]

I can confirm this bug on 2.1.10, fmode does not work.

My host is MacOS Leopard, guest ubuntu 810 with 2.1.10 GuestAdditions.

Using fmode I can not get both ux and uw at the same time.

To reproduce: try fmode=777. The permissions you get is user: xr group: xrw other: xrw

So, files can be created and executed but not changed, which makes shares almost unusable for real work. I tried the S_IXUSR modification suggested in this thread and it works, but only if I do _not_ use fmode. With the S_IXUSR change I get user rwx on all files: enough to be able to work.

[Samus_Aran]

Bug still exists in 2.1.0 Ubuntu Guest, Ubuntu Host.

Being unable to modify permissions within a shared folder renders the shared folders useless for many people. This is a critical bug.

Changing all files to rwx is no solution, the user needs to be able to naturally modify all permissions on and off, freely from within the virtual machine.

If the Host is not a system which allows per-file permissions to be stored, then the permissions could be stored in a supplimentary file along with that particular virtual machine configuration, in an XML file or similar. That or use Samba or similar which can handle permissions natively.

[Frank Mehnert]

jlundberg, indeed, there was still a bug in the 2.1.0 additions, see r15819. You can actually fix this typo manually in your guest (look at /usr/src/vboxvfs-2.1.0/utils.c) and recompile your guest additions with

/etc/init.d/vboxadd setup

After you successfully compiled the guest modules, reboot your guest. You should now be able to set fmask to 0777.

Samus_Aran, freely choosing the permissions of the files on the shared folders is not possible as the host might not support permissions. You might want to wish to support this for hosts which support permissions (e.g. Linux guest on Linux host). Yes, we will probably support this in future versions but currently we don't and we can't promise anything.

[Frank Mehnert]

Hrmpf, I was talking about fmode of course, not fmask.

[Erik Novales]

Just wanted to report that after applying r15819 to the guest additions for 2.1.0, the fmode option does work correctly. (host is XP SP 3, guest is Ubuntu 8.10)

[Ben Lau]

I have applied r15819 to the guest additions fro 1.6.6, the fmode option still do not work . (Host is Debian SID , guest is ubuntu 8.0.4)

[Frank Mehnert]

This patch was meant to be applied against the 2.1.0 additions. You have to apply r14598 as well, but this patch is against mount.vboxsf.c ...

[[email protected]]

I have the same problem. I have just tried your patch, and I'm not sure it made a difference. Now, root owns the files (I don't remember if that was the case previously), but I still cannot set execute permission on the files in the shared folder. Host is XP SP3, guest is Ubuntu 8.10.

[[email protected]]

Nevermind, setting fmode works correctly.

[oogabooga2000]

According to the VirtualBox change log, this bug has been marked as fixed in 2.1.2 (?)

[Frank Mehnert]

Indeed. The file permissions are settable with the fmode parameter.

[john_rogers]

Running VB 2.1.2, XP host, Ubuntu 8.10 guest. Please excuse if the question is naive.

ejtttje's fix worked for me to make the files executable. However, when I did this I lost full screen graphics. No guest-F, guest-G, etc., key combinations would restore. I tried to reinstall just the graphics driver with

sudo ./VboxLinuxAdditions-x86.run x11

but this of course undid the fix. Anyone run into a similar problem.

Thanks

[Frank Mehnert]

As I wrote in the previous comment, this bug is fixed. And the workaround isn't necessary anymore, provided that you are using the 2.1.2 guest additions.

[john_rogers]

Well perhaps I'm doing something wrong, but I installed 2.1.2. I mounted and installed the guest additions, and had the same problem. Even though I had umask set at 000, permissions were always rw-rw-rw- Couldn't chmod anything, couldn't execute anything, etc. Did the patch by editing utils.c, and now I have rwxrw-rw-

Have you verified yourself that it is indeed fixed in 2.1.2? This is my first install of VB, so it's hard to think I that I mixed up editions.

I have the following line in my etc/fstab for mounting on boot

Desktop /home/my_name/Desktop vboxsf umask=033,uid=1000,gid=1000,auto, 0 0

I'm a noob with this, so if I appreciate any further insights.

[Frank Mehnert]

Add fmode=777 to the mount options.

[john_rogers]

Frank, you're an Ace. That did it, and graphics works too!

Thanks for the help.