mount_options in config.vm.synced_folder error

[troymccabe]

Admittedly, mounted volumes & sharing is not a strong suit of mine, but I've tried everything I can think of to get this working & have been unable to. I'd appreciate any assistance you can provide (or tell me if I'm missing something)

Issue details

When using VirtualBox as the provider, I need to provide mount_options as so: [...rest of synced_folder config...], mount_options: ["dmode=775","fmode=664"]

When I attempt this using Parallels as the provider, I get the following:

$ vagrant reload --provision
==> default: Attempting graceful shutdown of VM...
...snip...
==> default: Mounting shared folders...
    default: /var/www => {HOST_DIR}
Failed to mount folders in Linux guest. This is usually because
the "vboxsf" file system is not available. Please verify that
the guest additions are properly installed in the guest and
can work properly. The command attempted was:

mount -t prl_fs -o uid=`id -u vagrant`,gid=`getent group vagrant | cut -d: -f3`,dmode=775,fmode=664 var_www /var/www
mount -t prl_fs -o uid=`id -u vagrant`,gid=`id -g vagrant`,dmode=775,fmode=664 var_www /var/www

When I remove mount_options, it goes through the mounting process fine, but fails on provision (this failure cascades into other provision actions):

Error: Failed to set group to '33': Operation not permitted - /var/www
Error: /Stage[main]/Main/File[/var/www]/group: change from vagrant to www-data failed: Failed to set group to '33': Operation not permitted - /var/www

I've also tried chowning & chmoding as the first item in the Puppet manifest, but still no go there either.

Relevant info

OSX version: 10.9.2
Parallels version: 9.0.24217 rev 979618
Vagrant version: 1.5.1
Box url: https://vagrantcloud.com/parallels/ubuntu-12.04/version/1/provider/parallels.box
Synced folder config:

  data['vm']['synced_folder'].each do |i, folder|
    if folder['source'] != '' && folder['target'] != '' && folder['id'] != ''
      nfs = (folder['nfs'] == "true") ? "nfs" : nil
      config.vm.synced_folder "#{folder['source']}", "#{folder['target']}", id: "#{folder['id']}", type: nfs, mount_options: ["dmode=775","fmode=664"]
    end
  end

Provider config:

  config.vm.provider :parallels do |parallels, override|
    override.vm.box = "dev-parallels"
    override.vm.box_url = "https://vagrantcloud.com/parallels/ubuntu-12.04/version/1/provider/parallels.box"

    parallels.name = data['vm']['box']
    parallels.memory = 512
    parallels.cpus = 2
    parallels.check_guest_tools = false
  end

[carcus88]

I was just about to create this issue. This started happening after this update
#100

I've noticed that its only if you try and mount the current folder

config.vm.synced_folder "./", "/tmp/path", id: "vagrant-root"

If you mount a folder further in it works fine such as

config.vm.synced_folder "./test", "/tmp/test", id: "foo"

This is killing me, I can't use the plugin anymore in this state because my application is in the root folder. Which is pretty much how most people use this I think.

[carcus88]

Just noticed that my root folder is not listed in /media/psf. I tried re-adding the share through the Parallels GUI interface but it just never appears in the share list no matter how many times I add it. I can add any other folder except the folder vagrant is operating out of. Funny thing was if I deleted all the other shared folder entries I could add the root folder.

[carcus88]

@troymccabe I think I may have had my issue and yours confused for the same thing, apologies if this is the case. You may want to look at this issue, I'm not sure but it could be related.

#105

[legal90]

@troymccabe
At first, dmode and fmode are strongly custom options for "vboxsf" filesystem. Thats why you are getting an error while using these options via the Parallels provider.
I don't know about the similar options for the "prl_fs" filesystem, I'll try to find this out at near days and will post the answer here.

Error: Failed to set group to '33': Operation not permitted - /var/www
Error: /Stage[main]/Main/File[/var/www]/group: change from vagrant to www-data failed: Failed to set group to '33': Operation not permitted - /var/www

Yes, since this is a mount point, it is impossible to apply 'chown'/'chgrp' to this folder. I suggest, that you will get the same error using the VirtualBox shared folders or NFS type.
http://www.unix.com/red-hat/178736-chown-changing-ownership-operation-not-permitted.html

[legal90]

@troymccabe Could you please describe your usage scenario of shared holders more detailed? Do you really need to have specified '775/664' permissions in your guest system?

Now I'm going to revert changes related to #100 and return back the 'Shared folders via symlinks' approach. It means that your shared folders will be mounted with default options as before the '1.0.3' release:

$ mount
...
vagrant on /media/psf/vagrant type prl_fs (rw,nosuid,nodev,sync,noatime,share)

nosuid and share means that all your users in virtual machine will have the same permissions as your host's MacOS account (#100 (comment))
Will it usable for you or not?

[troymccabe]

I figured that was the case with those flags, so no surprise there -- thanks for the info on that.

As far as the 775/664, that was necessary in Virtualbox for my application to write directories & files in them (prime example is a cache directory). Even with extremely liberal permissions on the host, the guest (in VirtualBox) would not be able to write the files to the mounted share. (http://stackoverflow.com/questions/18648547/laravel-4-permissions-on-a-vagrant-box-with-puppet & multiple other instances of this situation)

For whether it would be usable or not, I found the offending statement in my puppet manifest. For some reason, it worked in VirtualBox, but not in Parallels. I'll rewrite that section to support either, but things seem to be working after knocking that section out (even writing cache dirs & whatnot).

Thanks!

[legal90]

I finally decided to don't revert the #100 -related changes, but I've already fixed bugs what @carcus88 talked about.

Update to v1.0.5 (has been just released) and try to use mount_options: ["share", "nosuid"] to set 'liberal' permissions.

[troymccabe]

Working great--thanks!

[carcus88]

I've hit a wall again with placing my application in /var/www and sharing it as a synced folder. I've been trying with the 1.2.0.rc2 version as well as the current 1.1 version. I'm running an Ubuntu 14.04 machine.

The issue seems to be that when I use something like /var/www for my app and I install apache the dkpg command when trying to install apache tries to touch things on /var/www and set ownership.

Preparing to unpack .../apache2_2.4.7-1ubuntu4.1_amd64.deb ...
Unpacking apache2 (2.4.7-1ubuntu4.1) ...
dpkg: error processing archive /var/cache/apt/archives/apache2_2.4.7-1ubuntu4.1_amd64.deb (--unpack):
 error setting ownership of `/var/www/html.dpkg-new': Operation not permitted
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:

In testing I tried to touch a file in /var/www and chown it to root but it fails

$ sudo chown root:root test
chown: changing ownership of ‘test’: Operation not permitted

I've tried both

owner: 'www-data', group: 'www-data', mount_options: ["share"]

and

owner: 'www-data', group: 'www-data', mount_options: ["share, "nosuid"]

Both with the same results. Is there no way to mount this where ownerships can be modified?

[legal90]

@carcus88, it is so sad, but currently prl_fs (filesystem for Parallels Shared Folders in Linux guests) does not permit to change ownership of files and directories.
"Operation not permitted" will be displayed when you try to do chown every time, regardless of mount options

It was done especially to avoid ownership corruption for common cases of careless users.
There are some integration features in Parallels Desktop which enables sharing of very important directories of the Mac host machine (including user's home, and root partitions of disk drives). So, it is very dangerous to change ownership there.

I understand your case and I will try to talk at Parallels about that, but now chown is completely disabled for shared folders.

I suggest you to use NFS for this (with appropriate mount options):

config.vm.synced_folder '/path/on/your/host', "/var/www", type: 'nfs'

[bgronek]

nfs still does not allow setting of the owner. I wish this would have worked as I would much prefer parallels over virtualbox.

[paulecoyote]

@bgronek yeah it is a real shame and makes the entire product uncompetitive for this kind of problem.

[legal90]

@paulecoyote You are wrong. If we're talking about NFS, then "chown" problem is not related to any endpoint product such as Parallels Desktop, VirtualBox or Vagrant. It is definitely specific to NFS protocol/filesystem and, in our case to their BSD implementation: 'exports' man for OS X.

I'll try to explain the details...
To 'permit' your guest system to access shared folders/files, the appropriate filesystem should somehow map uid's and gid's between guest and host OSes. It is relevant to NFS and Parallels Shared Folders as well.

Since you're local host's files can be "chowned" only by your local "root" user, you should also map this root user with someone in the guest, if you want to allow him to "chown" your shared folders/files.

But by default Vagrant configures NFS exports on the OS X host with these options: "alldirs", "mapall=<map_uid>:<:map_gid>", where 'map_uid' and 'map_gid' is your current OS X user/group, which is running vagrant up command. So that, all guest VM's users (including root) can access to shared folders/files with permissions which your OS X user has.
Since your host's user is not permitted to do chown, then guest's root is not able to do this too.

Parallels Shared Folders don't allow you to do anything with it, but you can workaround it with NFS:
Please be careful, these both ways make it possible to do chown from guest, but they also make it easy to shoot yourself in the foot!

1. Permit guest's "root" user to interact with shared items as your host's "root":

config.vm.synced_folder '/path/on/your/host', "/var/www", type: 'nfs', bsd__nfs_options: ['alldirs', 'maproot=root:wheel']

2. Permit all guest's users to interact with shared items as your host's "root" (hope you will never do it):

config.vm.synced_folder '/path/on/your/host', "/var/www", type: 'nfs', map_uid: 'root', map_gid: 'wheel'

[bgronek]

Thanks for the input! I'll be sure to try this if I have to come back to
Parallels as a recent update to VirtualBox seems to have resolved my issue
with that tool (high cpu consumption). I was trying to make this work with
the same options used for virtualbox:

... owner: "www-data", group: "www-data", mount_options:
["dmode=777,fmode=777"]

I suppose these other options will lead to a greater chance of success at
mapping a web root to a shared folder.

Thanks!

On Sun, Oct 12, 2014 at 3:39 AM, Mikhail Zholobov notifications@github.com
wrote:

@paulecoyote https://github.com/paulecoyote You are wrong. If we're
talking about NFS, then "chown" problem is not related to any endpoint
product such as Parallels Desktop, VirtualBox or Vagrant. It is definitely
specific to NFS protocol/filesystem and, in our case to their BSD
implementation: 'exports' man for OS X
https://developer.apple.com/library/mac/documentation/Darwin/Reference/Manpages/man5/exports.5.html
.

I'll try to explain the details...
To 'permit' guest system to access shared folders/files, the appropriate
filesystem should somehow map uid's and gid's between guest and host
OSes. It is relevant to NFS and Parallels Shared Folders as well.

Since you're local host's files can be "chowned" only by your local "root"
user, you should also map this root user with someone in the guest, if you
want to allow him to "chown" your shared folders/files.

But by default Vagrant configures NFS exports on the OS X host with these
options: "alldirs", "mapall=<map_uid>:<:map_gid>", where 'map_uid' and
'map_gid' is your current OS X user/group, which is running vagrant up
command. So that, all guest VM's users (including root) can access to
shared folders/files with permissions which your OS X user has.
Since your host's user is not permitted to do chown, then guest's root is
not able to do this too.

Parallels Shared Folders don't allow you to do anything with it, but you
can workaround it with NFS:
Please be careful, these both ways make it possible to do chown from
guest, but they also make it easy to shoot yourself in the foot!

1. Permit guest's "root" user to interact with shared items as your host's
   "root":

config.vm.synced_folder '/path/on/your/host', "/var/www", type: 'nfs', bsd__nfs_options: ['alldirs, maproot=root:wheel']

2. Permit all guest's user to interact with shared items as your host's
   "root" (hope you will never do it):

config.vm.synced_folder '/path/on/your/host', "/var/www", type: 'nfs', map_uid: 'root', map_gid: 'wheel'

—
Reply to this email directly or view it on GitHub
#103 (comment)
.

[legal90]

UPDATE: In Parallels Desktop 10.1.2 it became possible to chown files from shared folders.
Now there is no error like "Operation not permitted" anymore 😃

You can update PD by clicking on the top menu "Parallels Desktop -> Check for Updates...", either download and install the latest build by this link: http://www.parallels.com/directdownload/pd10/

[hadronzoo]

@legal90 Do the updates in 10.1.2 make maproot=root:wheel irrelevant? I updated Parallels to 10.1.2 and updated the vagrant plugin, but chown is still not permitted unless I include the maproot option.

[legal90]

@hadronzoo

I updated Parallels to 10.1.2 and updated the vagrant plugin, but chown is still not permitted

I'd like to reproduce it.

1. Please, show all mount options in this case (mount output from the guest VM)
2. Do you have SELinux enabled? (for RHEL-based guests only). chown works only if SELinux is disabled or permissive.

[hadronzoo]

@legal90 my mistake—I am not getting permission errors from the guest VM. I'm running the parallels/boot2docker box and the chown problems are only occurring from within docker containers, so this is appears to be a docker issue (adding the maproot=root:wheel option does solve the problem).

[itsazzad]

@legal90
How is it to use?:

  config.nfs.map_uid = Process.uid
  config.nfs.map_gid = Process.gid