unable to perform some svn operations on shared folders from guest

[Marvin]

Host: Windows Vista

Guest: Gentoo

Description:

In the development, I need to use some collaboration system whose gui client in windows sucks. So I plan to share the project direcotries with my guest gentoo and then use the command line client in unix instead.
However, because the client depends on the result of 'svn status' and my netbeans uses its own SCM instead of the native one, I have to do this manually, which fails.
This is the error message when I perform some svn operation like 'svn add':

svn: Can't move '.svn/tmp/entries' to '.svn/entries': Operation not permitted

This will never happen if the underlying file system is local since I care little about anything inside the .svn directory. I try to chmod it 777 and find that somehow its permission will get "reverted" before svn starts its job.
The shared folders are mounted manually with default options. I can do whatever I wish but not with svn, which sounds weird. I hope this does help.
BTW, vbox rocks!

[Vito Botta]

I am having the same problem (and was about to open a ticket). Regardless of permissions etc, I have this issue with SVN in a Ubuntu guest on Windows as host.

I guess it has something to do with limitations with the NTFS file system, although am not sure (or, better, limitations in the way Windows uses NTFS, because - if I remember rightly - NTFS supports file names starting with dots etc)

I am using these settings in my fstab to mount the folders shared on the Windows host:

(share name) (mount location) vboxsf rw,gid=1000,uid=1000,auto,exec 0 0

As a workaround for the time being, I am mounting the shares as normal network shares and with these settings all works just fine:

xxx.xxx.xxx.xxx/(share name) (mount location) cifs username=*,password=*,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777,noserverino,gid=1000,uid=1000 0 0

I haven't tested the performance difference so am not sure if this is much slower or otherwise, but having both the physical network card on the host and the virtual one on the guest set as Gigabit with Jumbo frames, it's pretty fast anyway.

But it'd be nice if vboxsf shared folders worked

[Frank Mehnert]

Actually this could be a duplicate of #4890. If so then r28253 should fix the issue. This patch can be applied manually to the files in /usr/src/vboxvfs-3.1.6/. After that, recompile the guest additions kernel module (/etc/init.d/vboxadd setup) and reboot the guest.

[Marvin]

Actually, I tried to follow the instructions in #4890 and here is the result.

marvin@gentoo ~/temp $ touch test1 test2
marvin@gentoo ~/temp $ chmod a-w test2
marvin@gentoo ~/temp $ mv -f test1 test2
mv: cannot move `test1' to `test2': Operation not permitted

The temp directory is a shared directory on the host. It is mounted with "defaults" option on Gentoo. I'm not sure whether I can interfere with the default mount options. If I can, please tell me how I can find what this option means so I can provide more details here.
BTW, how can I find the revision of the virtual box core? I find a revision called r59338 which seems not a valid one... Anyway, I can't find an update via "Check for Updates..." in the "Help" menu so my box should be up to date.

[Marvin]

Sorry for the revision stuff since I just found that r28253 is fresh new.
So it is supposed to get fixed in the next release, right? Can't wait anymore.
VBox rocks!

[Siarhei]

Just ran into same issue on XP(sp2) host with vbox 3.2.8 and Ubuntu 10.04 as guest - tried to do

svn co 

to the shared folder.

[Hugo Ideler]

Still present in 3.2.8. Both git and svn do not work on shared folders (win7 host, archlinux guest).

[Hugo Ideler]

Without very thorough testing, I can conclude the tip from vitobotta also works for me as temporary fix.

[PVillela]

This problem impacts me with VirtualBox 3.2.8, Windows 7 host, Ubuntu 10.04 guest, both 64-bit. The workaround from vitobotta is very helpful. But why can't VirtualBox get its shared folders to work correctly? This is not the only shared folder bug, though it's an important one as a lot of people use VMs for software development and Subversion is one of the most popular version management tools. I'm stuck on VirtualBox 3.2.8 because of even flakier shared folder behavior on a later version (I forget which one), so I regressed to 3.2.8.

[Hugo Ideler]

I can confirm it has not been fixed in VBox version 4 yet.

My preferred workaround is now to use git-svn. It sometimes fails on vboxfs, but most of the time functions fine whereas subversion never works. I would recommend it above using cifs.

[olegych]

confirmed with 4.0.4, win7 x64 host, maverick x64 guest

[Ken Yee]

Ditto confirmation w/ VirtualBox 4.0.4 (Windows Vista 32-bit host, Debian Squeeze 64-bit as guest)

[mszulc]

Bugs still exist in 4.0.6 (Host: Windows SP3 (x86) with all updates; Guest: Ubuntu 10.10 x86 with all updates and Guest Additions 4.0.6)

[rewen]

Same problem still exists in 4.2.16 on Win7 x64.

Extremely frustrating. I have no valid workarounds at the moment.

[vipinb]

I am facing this same issue on Virtualbox 4.3.20 Host - Windows 7 Guest Oracle Linux 5

[jesusch]

+1 on this (4.3.20)

[GDomino]

Problem still exists as of 5.0.14 r105127 (Win7 x64 host, Ubuntu 12.04 x64 guest)