Hello, What can be, is the sharedfolder tries to emulate on the guest what it sees on the host. and linux/osx have a more easy task..
and in the windows box, your bash does a better job than the virtualbox shared folder. (both are emulating a bit) If I get a request to make the permissions to work , and they are on git, I will do the git clone inside the guest on a real filesystem. around this idea, couple of crazyness can be used if you want to say make the work survive a vagrant destroy, but will be workarounds and manual work, that I am not sure if will worth the time, etc sorry for not being more helpful on this one, but is a tricky one.. On Wed, Aug 6, 2014 at 7:30 AM, Lon Binder <[email protected]> wrote: > Thank you Alvaro! I tried both options B & C you mentioned; they work > similarly (as expected) to what I had tried, which is that they override > all the permissions, whereas I need to maintain the permissions. > > To answer your two questions: > > 1. Why do I expect to see the perms stay the same: > Because when I'm in MinGW <http://www.mingw.org/> I see the correct > permissions. Some files have +x; some don't. These are checked out from Git > and the bit is set correctly (at least it visibly looks right from an ls- > al). To me, this means the information is available on my host somewhere, > therefore there should be some way to make this bit known to the guest VM. > > It is hard (for me) to tell whether the executable bit is actually set > locally because the linux emulators have tendency to look for and guess the > +x flag for files that *look* like executables (such as these rules > <http://www.cygwin.com/faq.html#faq.api.executables>). However, I > compared the settings to those on my OSX colleagues' machines and the > settings in my env match theirs. (could be coincidence). > > 2. Why I want this: > Because some files are executable and should be. For instance, scripts > need to be executable. Other files are not executable and shouldn't be > (mostly because ansible complains when they are). > > Thanks again! > > > > On Monday, August 4, 2014 6:26:41 PM UTC-4, Alvaro Miranda Aguilera wrote: > >> Hello >> >> Please, relax, what I am going to write can be sound weird (it's weird >> actually) >> >> but, you have 2 Filesystems that are not a real filesystem. >> >> Let me explain. >> >> The guest is linux, so, linux understand what rwx rwx rwx are >> user-group-other >> >> but, neither virtualbox shared folder neither windows have those >> permissions >> >> if in windows you do dir /a >> >> you will see a lot of information, but no permissions at all.. >> >> ntfs have some sort of ACL (access control list) >> vfat/fat32 they only do 777 for directories and 666 for files >> >> so trying to see on the linux guest what you have in windows over >> virtualbox shared folder will be probably a big headache.. >> >> but! is not needed. >> >> you have few options >> >> A. Use windows filesharing and samba client on the guest, so windows will >> do the checks on user/group but this is not rwx rwx rwx or user-group-other >> >> if the user that is trying to mount have user or group access, and >> match, etc. will mount then will be able to read/write etc.. >> >> B. Use virtualbox sharefolder and set gid/uid/dmode=770/fmode=660 and >> make the user that will use these files to have acess to use it >> >> C. use dmode=777,fmode=666 >> >> >> now, with this little explanation, can I ask.. Why do you expect see the >> same permissions from the windows bash inside the vm? >> >> if you were using linux/osx -> nfs -> linux guest, sure, you will >> >> but in any other combination, i don't think it will, and is not required >> to be. >> >> more than happy to assist, just share why/what you want this, so I can >> can understand.. >> >> at this moment, I will say go for my suggestion C or B >> >> Alvaro. >> >> >> >> On Tue, Aug 5, 2014 at 10:00 AM, Lon Binder <[email protected]> wrote: >> >>> Files permissions are getting changed inside the guest host for shared >>> folders. >>> >>> Running VirtualBox 4.3.12, controlling via Vagrant 1.6.3, on Windows 7 >>> Pro SP1, operating a guest of CentOS 6.5, all via MINGW32_NT-6.1 (inside >>> Atlassian SourceTree Shell). >>> >>> From MINGW32 shell, example output of ls -al within a folder to be >>> shared: >>> drwxr-xr-x 1 lon.bind Administ 4096 Aug 4 09:06 group_vars >>> -rw-r--r-- 1 lon.bind Administ 211 Jul 24 18:20 hosts.office >>> -rwxr-xr-x 1 lon.bind Administ 153 Jul 24 18:20 hosts.dev >>> -rwxr-xr-x 1 lon.bind Administ 153 Jul 24 18:20 hosts.lab >>> -rwxr-xr-x 1 lon.bind Administ 154 Jul 24 18:20 hosts.mgmt >>> >>> >>> Those are all exactly as they should be. >>> >>> From within CentOS VM, same command from inside the shared folder: >>> drwxrwxrwx 1 root root 4096 Aug 4 13:06 group_vars >>> -rwxrwxrwx 1 root root 211 Jul 24 22:20 hosts.office >>> -rwxrwxrwx 1 root root 153 Jul 24 22:20 hosts.dev >>> -rwxrwxrwx 1 root root 153 Jul 24 22:20 hosts.lab >>> -rwxrwxrwx 1 root root 154 Jul 24 22:20 hosts.mgmt >>> >>> >>> Now everything is root and 777. >>> >>> If I change my config.vm.synced_folder mount_options I can alter the >>> owner, the group (same as if I change mount options in remounting the >>> shared folder). I can forceably override the file perms as well, using >>> either umask or fmode -- this makes all files the same. They should be >>> individually set as they originally are. >>> >>> For example, can override like this: >>> config.vm.synced_folder VagrantUtil.src_code_dir(), "/opt/wp/app", owner >>> : "vagrant", group: "vagrant", :mount_options => ['dmode=777', >>> 'fmode=770'] >>> >>> How do I get the permissions to remain as they are in the host? >>> >>> Halp! Alvaro, save me :-) >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Vagrant" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "Vagrant" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Vagrant" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
