-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
config.vm.synced_folder Always mounts as vagrant #100
Comments
Thanks for a response, I've investigated the Shared Folder mounting in Parallels-based Linux machines.
Currently we are using a ParallelsTools approach to mount shared folders. Our provider only creates a symlink to the appropriate mount point But...
It's not quite right. Parallels Tools daemon is mounting shared folders using the next default options: $ mount
...
vagrant on /media/psf/vagrant type prl_fs (rw,nosuid,nodev,sync,noatime,share) See "man mount" to get more info about these options. Since [vagrant@host ~]$ ls -l /media/psf/
drwxr-xr-x 1 vagrant vagrant 748 Mar 17 23:10 vagrant
[vagrant@host ~]$ sudo ls -l /media/psf/
drwxr-xr-x 1 root root 748 Mar 17 23:10 vagrant
[vagrant@host ~]$ sudo -u puppet ls -l /media/psf/
drwxr-xr-x 1 puppet puppet 748 Mar 17 23:10 vagrant So, you should not have any problems with access to these folders, right? |
Right I don't have any problems accessing the files and now it makes sense why I saw some mounts as vagrant and some as root because now that I go back and
I see it as root or whoever I'm sudoing as. This also explains why my app seems to have the correct permissions in Apache because it runs as www-data and sees the mounted files as www-data. I was confused why things worked when it seemed like they should not given the fact they appeared to be owned as vagrant. I'm also concerned that others may chase this too only to find out the same thing. Is the proper thing to do here mount it as the user/group specified and use the nosuid option if nothing was asked for, or is this not a bug because of the use of nosuid? |
* master: guest_cap/linux: Clear prior symlinks while 'mount_parallels_shared_folder' [GH-100] guest_cap/linux: Changed 'mount_parallels_shared_folder' - use advanced mount instead symlinks [GH-100] cap: Added 'host_address' provider capability driver: Added method 'read_shared_interface' driver: return nil if 'parallels_dhcp_leases' file does not exist [GH-99]
Fixed in v1.0.3 Now, in Linux guests shared folders are mounted directly to the specified path instead using a symlinks. It is possible to use mount options |
Turned back an advanced synced folders for Linux, close to approach of VirtualBox provider: - Possibility to set mount options [GH-100] [GH-103] - Shared folders aren't missed after suspend/resume, [GH-102] is fixed - It is possible to share single folder to the some mount points, [GH-105] is fixed Changes related to Parallels Desktop 10 Closed Beta: - Port Forwarding feature added. SSH sessions are working through the forwarded port by default. - All Password Restrictions will be disabled while the `vagrant up` [GH-67] Bunch of refactoring
Sorry to highjack this but I have been trying for months to mount shared folder as non-root and failed. I have a thread on https://forum.parallels.com/threads/how-to-mount-psf-shared-home-folder-as-a-non-root-user.338151/ and opened two tickets with Parallels support. They were not able to provide anything useful so far. |
@ssbarnea, seems |
@romankulikov Thanks! I was able to solve the problem using this approach: |
I have not been able to find any combination of mounting options that will allow me to mount a synced folder as anything but vagrant
I have tried
:owner => 'www-data', :group => 'www-data'
And
owner: 'www-data', group: 'www-data'
But no matter what every time i do a
vagrant reload
The mounts are always vagrant. From the code in this provider it looks like it should be obeying the option but never seems to. This is happening with Vagrant 1.4.1
and Parallels 9
Does anyone else have the same issue or know of a work-around?
The text was updated successfully, but these errors were encountered: