Serious bug in VirtualBox 3.0 - file permisions messed up in shared folders!

[yesint]

Dear All,
I've upgraded VirtualBox to 3.0 and immediately went into serious trouble. I have Ubuntu 9.04 host and WinXP guest. If I open a file in MS Word, which is located in the shared folder (physically located on Ubuntu host) and then save it. After save the permisions for this file become -r-------- regardless of initial permissions!
As a result the next save fails with the message "the file is read-only". It is said that this bug was already fixed in 3.0beta, but it does not!!!

[bkraptor]

You can temporarily fix it by chmod u+rw filename in a terminal on the host.

[Perryg]

I just tested this and it retains the permissions for me. I do not have Word on the Windows XP guest but did use wordpad. Can you send me the bug ticket that you are referring to so I can check it out for you?

[yesint]

I just tested this and it retains the permissions for me. I do not have Word on the Windows XP guest but did use wordpad. Can you send me the bug ticket that you are referring to so I can check it out for you?

The closest one is probably #3785 and a bunch of related bugs. I also posted this problem to VirtualBox forum and some other troubles seem to exists as well http://forums.virtualbox.org/viewtopic.php?f=2&t=19465

[yesint]

You can temporarily fix it by chmod u+rw filename in a terminal on the host.

Try doing this each time when you want to save changes in your text and you'll understand the "usefulness" of this workaround

[Perryg]

What are you using for your mount statement?
I found that the best way was to put the mount in the rc.local file see below.

mount -t vboxsf -o rw,gid=1000,uid=1000 Shared /mnt/Shared

Where Shared is the share name you used in VBox and the complete path to the mount. uid & gid are your numbers.
Check them by running id in terminal, but they should be 1000 if this is the original install login you used.

[yesint]

What are you using for your mount statement?
I found that the best way was to put the mount in the rc.local file see below.

mount -t vboxsf -o rw,gid=1000,uid=1000 Shared /mnt/Shared

Where Shared is the share name you used in VBox and the complete path to the mount. uid & gid are your numbers.
Check them by running id in terminal, but they should be 1000 if this is the original install login you used.

I created shares using VrtualBox GUI and then enabled them in the guest with "net use x: \\vboxsvr\share-name"
I can't see how this can make any difference with permissions...

[Perryg]

Ooops, Sorry I had it backwards. Your guest is Windows. I have a notebook that I use for Ubuntu and run XP on it and the home system is Vista with Ubuntu on it. That way I can test both directions. I have tested this though on my system and do not have this problem, so what we need to do is see what the difference is. One thing that sticks out is the share name with the - in it. While this should not matter to Windows it does mess with Linux. Could you try to change the name and remount and see if this changes anything. Also no caps, or special characters in the share name. Also what is the mount point (folder) that you are sharing? Is it a folder in your home folder? Does the VBox user have full rights to this folder?

[yesint]

I have tested this though on my system and do not have this problem, so what we need to do is see what the difference is.

I suspect that this bug is "bad" in the sense that it only pops up in specific conditions. However, it is already confirmed http://www.virtualbox.org/ticket/4381 and it seems to affect mostly MS Office programs.

One thing that sticks out is the share name with the - in it. While this should not matter to Windows it does mess with Linux. Could you try to change the name and remount and see if this changes anything. Also no caps, or special characters in the share name. Also what is the mount point (folder) that you are sharing? Is it a folder in your home folder? Does the VBox user have full rights to this folder?

The name of the share is just "work". The path in the host is "/home/semen/work" - nothing confusing.

[stickleback99]

Does the same for me too!
Thanks yesint for highlighting this bug, it was driving me nuts.
I don't have any NTFS partitions so I can't say wether or not it behaves ok with these (as the report from your link suggests).
However on my shared folders (which happens to be Ubuntu /home) within an MS Word the first save of a new file is ok, any further attemts to save render the file read only.
If I open an exiting file in my shared folder with MS Word it makes it read only immediately.