[Solved] shared folders not accesible any more

[fluid_02]

I have Virtualbox on Linux opensuse leap 42.1 64-bit and one of the guests is Windows 2000. After an upgrade recently to 5.1-5.1.16_113841 an application fails to see and open a whole directory which is mounted as a shared directory which is a linux directory and mounted under W: (if that is the correct wording). When I try to open the sub-directory W;\dwgboard\drawings (the name is visible) from witthin the application, the error message is "You do not have permission to open this directory". But if I use the Windows file explorer, there is no problem, I can go to that sub directory, open it, see all the files and can open the files. The application (which is 16 bit) has always worked for years and I have not made any change in the Windows guest. What has happened?

Help would be very much appreciated.

Fluid_02

[fluid_02]

problem solved: although I added the guest additions with VboxManage after the upgrade, it appears that I needed to add the guest additions (also?) from with in the Windows guest. After I did that, it now works again.

[socratis]

I needed to add the guest additions (also?) from with in the Windows guest.

The Guest Additions (GAs), as the name implies, are to be installed on the guest. Only on the guest.

The GAs should match the VirtualBox version for best compatibility/performance. You should remember that for the next time that you update/upgrade VirtualBox.

Glad you resolved it and thanks for the update. I'll mark it as [Solved].

[fluid_02]

Sorry, no, problem not solved. It worked, and I could open my file from within the application, but after working I could not save the file to the W: directory, not with the old, nor with a new name (no write access). I could save it under C: though. When I restarted the application, I had the original problem, the whole directory could again not be opened again. Very odd.

Fluid_02

[socratis]

Follow a "start from cold-boot", "observe error", "shutdown" cycle. With the VM shut down completely (not paused or saved), right-click on the VirtualBox Manager and select "Show Log". Save the first "VBox.log" only, ZIP it and attach it to your response (see the "Upload attachment" tab below the reply form).

[fluid_02]

Sorry, this was a strange red herring. It appears that on Linux the directory structure had mixed upper/lower case characters and this inhibited this 16-bit application to save files in these directories. Adding upper case symbolic links solved the issue. So, nothing to do with VirtualBox (I think?). The strange thing is all did work until, say, a week ago and coincided with the latest upgrade of VirtualBox.

Thanks for your quick replies, Fluid

[socratis]

The strange thing is all did work until, say, a week ago and coincided with the latest upgrade of VirtualBox.

Check out ticket 16549: Shared folder became case sensitive after update to 5.1.16 (Centos 7.3 Hosts/Win10 Guest) which was opened two days ago. I think you might be facing the same "problem". I don't know if it was intentional or not, but the best way to get notified would be to add a comment to the ticket, stating your use case.

[robertwork]

The strange thing is all did work until, say, a week ago and coincided with the latest upgrade of VirtualBox.

Check out ticket 16549: Shared folder became case sensitive after update to 5.1.16 (Centos 7.3 Hosts/Win10 Guest)...

My problem is not case sensitivity. The problem is that files are randomly accessible or not. For example, when I compile in Visual Studio, a different (random) set of include files cannot be opened on each compile. In any case, downgrading to 5.1.14 is a workaround.

[socratis]

In any case, downgrading to 5.1.14 is a workaround.

As the comments on the ticket state, updating to the latest test builds (details in the ticket) should also fix the problem. Please confirm.

If they don't, you might be having a different problem and we need to take a fresh look at it.

[robertwork]

(not directly related) I assume that there is no .deb (I'm running Debian Jessie) test build? I'm afraid of running the .run file in fear that it will result in a double-install situation.

[robertwork]

(not directly related) I assume that there is no .deb (I'm running Debian Jessie) test build?

Never mind. I went ahead and uninstalled the debian package and installed via the .run .

Everything now works fine. So, it indeed must be the same problem.

[socratis]

Thank you for taking that leap of faith. BTW, 5.1.18 just came out
Marking as [Solved].