Shared folder file permissions - changed in 3.0.4?

[sagemintblue]

I'm having the same trouble it seems..

VBox: 3.0.6
Host: Win7 RC 64
Guest: Ubuntu 9.04 64
Mount line: sudo mount -t vboxsf -o rw,exec,uid=1000,gid=1000 projects /mnt/projects
Subversion: 1.6.5

When I try to perform a checkout or update with the svn client I run into a permissions error on a file move operation:

Code: Select all

svn: Can't move '.svn/tmp/entries' to '.svn/entries': Operation not permitted
$ ls -l .svn/entries
-r-xr-xr-x 1 user user 156 2009-10-03 01:40 .svn/entries

It seems as though the APR library which the svn client uses for file related operations may be assuming too much about the underlying filesystem's capabilities:

http://subversion.tigris.org/ds/viewMes ... geId=81629

alan.wood@clear.net.nz wrote:

Hi
I have been looking at svn and samba recently, but only with the windows client.
There are comments in the windows versions of apr_file_rename() regarding not
being able to rename when the destination file is R/O on windows, you can do this on
unix. The problem is probably in this area where the apr routines on a unix client
expect the rename() library call to be able to rename over a read-only file irrespective
of the file system referenced.

Yes, that is correct. The Windows (and IIRC Cygwin) code path explicitly
resets the read-only flag on a file before attempting a rename. The Unix
code path does not. This implies that, if your working copy is on a
mounted volume shared from a Windows server, things will most likely
break horribly.

-- Brane

So any thoughts on how to avoid this problem within vboxvfs? There seems to be a Samba solution in the linked thread..

[Syntaxeus]

I have too this very same problem, and found no solution for it.
I tried using the

Code: Select all

chattr -i

command on the .svn folder, but then I get the

Code: Select all

Inappropriate "ioctl" for device while reading flags

[marckarasek]

Has there been any resolution on this issue?

I am running into the same problem with Win 7 Host and a Fedora 10 Client.

[SePPeR]

I'm having the same problem with Ubuntu Server as Guest OS.

Any solution?

[Sasquatch]

I just did a checkout with the SVN client on my compile VM (running Ubuntu 8.10) and I had no problems finishing it. It checked out to my shared folder, mounted as follows:

Code: Select all

sudo mount -t vboxsf -o uid=1000,gid=1000,rw,exec data /hosts/data

Running svn co <url to trunk> gave no issues whatsoever. All files are rw for me, then r--r-- (group, other).

[cyspotts]

I am having the exact the problems as many of the previous posters. When I try and checkout with svn, I get the same error as mentioned above.

I mounted with the following command:

mount -t vboxsf -o uid=1000,gid=1000,rw,exec,dmode=0755 mydocs /mydocs

and am running a fedora guest

Any suggestions would be helpful

[Sasquatch]

Tried it without 'dmode=755'?

[grichards]

Hello.

Host: Win7 64bit
Guest: CentOS5.5 32bit

I am having similar trouble.

After mounting as recommended in this thread (-o uid=xxx,gid=xxx,rw), all files and folders report 777 for user, group, world, except for .svn/entries and .svn/dir-prop-base which reports 555.

In other, but I think related trouble, file permission change behavior is just odd all around.

There is no way to remove the executable bit from the files and folder. The only possible modes are 777 or 555. I cannot change a file permission to 644 for instance. 777 reports instead.

[Sasquatch]

File and directory permission bits with VB's SF are the same idea as with any other non-Linux FS (like NTFS): it's done in the mount options. I can't chmod a file on my NTFS partition to change it from 644 to 755 for example. I have to remount the NTFS partition and include the 'exec' option.

Because of this way, it's very odd that a new file or folder would not inherit these permissions. As I posted before (either here or in a different topic), a check-out of SVN did NOT change anything for it's permissions nor cause an error.

[olegych]

File and directory permission bits with VB's SF are the same idea as with any other non-Linux FS (like NTFS): it's done in the mount options. I can't chmod a file on my NTFS partition to change it from 644 to 755 for example.

Apparently this is not true, and hurts interoperability pretty badly.
http://www.virtualbox.org/ticket/4890
http://www.virtualbox.org/ticket/5568

[lipi]

For those desperately looking for a workaround, below is a hack I just added to svn_io_remove_file and svn_io_file_rename in subversion-1.6.12. It works for me but still needs dmode=755 in the mount options.

Code: Select all

--- subversion/libsvn_subr/io.c	(revision 1079652)
+++ subversion/libsvn_subr/io.c	(working copy)
@@ -1825,6 +1825,13 @@
   SVN_ERR(cstring_from_utf8(&path_apr, path, pool));
 
   apr_err = apr_file_remove(path_apr, pool);
+  /* begin hack for vboxsf: force write permission before remove */
+  if (apr_err) {
+      SVN_ERR(svn_io_set_file_read_write(path, TRUE, pool));
+      apr_err = apr_file_remove(path_apr, pool);
+  }
+  /* end hack for vboxsf */
+
 #ifdef WIN32
   if (apr_err)
     {
@@ -2912,6 +2919,13 @@
 
   status = apr_file_rename(from_path_apr, to_path_apr, pool);
 
+  /* begin hack for vboxsf: force write permission before rename */
+  if (status) {
+      SVN_ERR(svn_io_set_file_read_write(to_path, TRUE, pool));
+      status = apr_file_rename(from_path_apr, to_path_apr, pool);
+  }
+  /* end hack for vboxsf */
+
 #ifdef WIN32
   /* If the target file is read only NTFS reports EACCESS and
      FAT/FAT32 reports EEXIST */

[phatrick]

I Wonder if there will be a solution to this. A rather clunky workaround is just to zip the checked out folder up and pass this between guest and host.

[kenyee]

For those desperately looking for a workaround, below is a hack I just added to svn_io_remove_file and svn_io_file_rename in subversion-1.6.12. It works for me but still needs dmode=755 in the mount options.

Did you submit this to the subversion folks?

[kenyee]

FYI, I reported the patch to the subversion issue tracker. Hopefully it'll be an official patch since it looks like it's non-harmful...

[kenyee]

Looks like subversion 1.7 (you have to build it out of their trunk) handles this quirk in virtualbox's shared folders. However, if you have any symbolic links in your repo, you'll bomb out with this error which doesn't seem to be a permissions issue:

http://www.virtualbox.org/ticket/8728