Shared folder file permissions - changed in 3.0.4?

[J2R]

I have an Ubuntu 9.0.4 guest running under a Vista host, and I have recently upgraded to 3.0.4 (from v2). I am finding that there is some change in file permissions in files in a shared folder. I am using Subversion in Ubuntu to do source control for some projects which I have in the shared folder and since the upgrade it no longer works properly because it can't delete certain files. In fact, even as root I can't delete those files and have to do so from within Vista. Has there been some change in shared folders with 3.0.4? The Vista host file system is NTFS, if that is relevant.

[Perryg]

When you updated to the new version did you uninstall the older version first?
Sometimes this prevents files from being copied properly if you did not uninstall first.
As always be sure that you back up before you try this. By default you should not have a problem but things happen.

[J2R]

When you updated to the new version did you uninstall the older version first?

Yes, I uninstalled first.

[Perryg]

Strange. I have Vista host and Ubuntu 9.10 guest. I do not have file permission problems.
Can you run ls -al in the share from Ubuntu and see what the permissions are?
Would it be possible to post the results?

[J2R]

Strange. I have Vista host and Ubuntu 9.10 guest. I do not have file permission problems.
Can you run ls -al in the share from Ubuntu and see what the permissions are?
Would it be possible to post the results?

Running ls -alh in one of the problematic .svn directories results in this:

Code: Select all

drwxrwxrwx 1 john john 4.0K 2009-09-05 18:15 .
drwxrwxrwx 1 john john  40K 2009-09-05 18:17 ..
-rwxrwxrwx 1 john john   37 2009-08-05 12:45 dir-prop-base
-r-xr-xr-x 1 john john  403 2009-09-05 18:15 entries
-r-xr-xr-x 1 john john    2 2009-09-05 18:15 format
-rwxrwxrwx 1 john john    0 2009-09-05 18:15 lock
-r-xr-xr-x 1 john john   32 2009-09-05 18:15 log
drwxrwxrwx 1 john john    0 2009-08-05 12:46 prop-base
drwxrwxrwx 1 john john    0 2009-08-05 12:46 props
drwxrwxrwx 1 john john    0 2009-08-05 12:46 text-base
drwxrwxrwx 1 john john 4.0K 2009-09-05 18:15 tmp

The file 'log' cannot be deleted, even by root (i.e., 'sudo rm -f log' tells me the file can't be deleted). I can, however, delete it from the Vista side.

[Perryg]

Looking back at the change logs and a few tickets on bugtracker there has been some changes in the shared folders since version 2. There have not been a lot of tickets submitted since version 3.x.x but it may be due to some other issue. I would suggest submitting a ticket so the Dev's can see what the problem is. Link to bugtracker is at the bottom of my post.

[Sasquatch]

The files that you can't remove don't have the write mode. All they have is read and execute. Without the write bit, you can't remove the file. I would investigate how to get that working before submitting a bug. How do you mount the share? Using -o uid=1000,gid=1000,rw,exec?

[J2R]

I'll investigate this and report back. It did all work before the change from v2 to 3.0.4, though.

LATER: Added in the 'exec' but no change. All the files which Subversion has to work with are apparently uneditable by any Linux user. I don't know what is specific about those files, but there are other oddities. No matter what I do, I now find I cannot change the owner or the permissions of the top level shared folder (i.e., /mnt/share, the mount point I have used for my Shared folder). I will continue digging and see if I can make sense of it all.

[J2R]

OK, I started a completely new Subversion repository and there is definitely a weird problem here. Subversion fails to work because it cannot delete the files it needs to. I just created a dummy project in my home directory (not the shared folder) and Subversion committing etc. works fine. I then created a second dummy project in the the shared folder and tried the same thing. This time this error occurred:

Can't move '/mnt/share/projects/JavaApplication7/.svn/tmp/entries' to '/mnt/share/projects/JavaApplication7/.svn/entries': Operation not permitted.

This is because the file '/mnt/share/projects/JavaApplication7/.svn/entries' cannot be overwritten (unlike in the case of my dummy project in the the home directory). Looking at it, it has different permissions, namely '-r-xr-xr-x' instead of '-r--r--r--' in the successful one, although I don't know why this should be.

[Sasquatch]

Files that need to be removed must have the write bit on, any change (write, modify and remove) are not allowed. Or at least, it shouldn't be allowed.

[Perryg]

The OP never stated how the mount statement is written. I have mine in the rc.local file as
mount -t vboxsf -o rw,gid=1000,uid=1000 Shared /mnt/Shared and do not have a problem with shares. You can add the exec switch but I never use it so it was not important to me.

[J2R]

Files that need to be removed must have the write bit on, any change (write, modify and remove) are not allowed. Or at least, it shouldn't be allowed.

But with Subversion working with files NOT in the shared folder, the read-only permissions aren't causing a problem. There's something different about the shared folder.

[J2R]

The OP never stated how the mount statement is written. I have mine in the rc.local file as
mount -t vboxsf -o rw,gid=1000,uid=1000 Shared /mnt/Shared and do not have a problem with shares. You can add the exec switch but I never use it so it was not important to me.

I had it exactly as yours. I added in the exec switch after Sasquatch suggested it, but it didn't help.

[Perryg]

Have you tried to see if adding a user account to Vista matching your Linux login will change anything. Then make sure that this person has permissions that would allow this on Vista? Or you could simply go to network sharing and see if this works. Kind of pulling for straws I know but as I said I don't have this problem and not sure how to replicate it on my end.

[J2R]

Have you tried to see if adding a user account to Vista matching your Linux login will change anything. Then make sure that this person has permissions that would allow this on Vista? Or you could simply go to network sharing and see if this works. Kind of pulling for straws I know but as I said I don't have this problem and not sure how to replicate it on my end.

My next step is to see if the problem is present using Samba instead of shared folders. I'll report back.