Shared Folder Stopped Working

[RobinK]

Host Operating System: openSUSE Leap 15.4
KDE Plasma Version: 5.26.5
KDE Frameworks Version: 5.101.0
Qt Version: 5.15.8
Kernel Version: 5.14.21-150400.24.38-default (64-bit)

Guest: Windows 11, with Guest Additions installed.

VirtualBox Version: 7.0.4_SUSEr154605

ExtPack Version: 7.0.4 Revision 154605

I don’t know exactly when, or what I was doing at the time, but at some point in the last few days I’ve lost access from the Windows guest to my shared folder on the Linux host.

The shared folders selection in the Settings of the VM is correct. The Details page of the VM says there is one shared folder. The former shortcut to the shared folder shows up on the running VM desktop. But the latter is inaccessible, and there’s no sign of the shared folder in the file manager.

I’ve re-installed the Guest Additions (several times), but to no avail.

Is there anything else I can do about this, please? I attach a .zip of the Vbox.log

[mpack]

What are you trying to share? I ask because the log contains this line:

00:00:01.099551 rtldrNativeLoad: dlopen('D3DCompiler_47.so', RTLD_NOW | RTLD_LOCAL) failed: D3DCompiler_47.so: cannot open shared object file: No such file or directory

[fth0]

@mpack:

FWIW, the log message regarding D3DCompiler_47.so has nothing to do with Shared Folders. The "shared object file" relates to the file extension ".so". Linux shared object files are the equivalent of Windows DLL files.

Additionally, you can regard this log message as a red herring. According to aeichner, the D3DCompiler_47.so library is used for debugging the graphics implementation (on Linux hosts, if available).

[mpack]

Yes, that line in the log didn't look very promising, but it was the only unexplained mention of sharing that I found there. I.e. no reference to any attempt to share a host folder.

@RobinK: please the ".vbox" file associated with this VM, and attach the zip here.

[fth0]

00:00:01.060330 Shared Folders service loaded
[...]
00:00:01.098579 SharedFolders host service: Adding host mapping
00:00:01.098585     Host path '/vms/VMShare', map name 'VMShare', writable, automount=true, automntpnt=, create_symlinks=false, missing=false
[...]
00:00:04.477416 VMMDev: Guest Log: VBoxSF: g_fHostFeatures=0x8000000f g_fSfFeatures=0x1 g_uSfLastFunction=29
[...]

The VirtualBox Shared Folders host service was started and successfully added the host mapping, so everything is ok on the host side of things. Not so in the guest OS: The VBoxSF.sys driver was started successfully, but not the VBoxService.exe service (no log messages). The VBoxTray application then was started successfully again.

I'd suggest to check in the Windows Event Log for errors regarding VBoxService.exe.

[RobinK]

I'm only an ignorant tinkerer, not an expert, but I did find in the Windows Event Viewer at least one reference to an error in VBoxService under Windows Logs > System.

The particular message reads "The VBoxService service failed to start due to the following error: The file or directory is corrupted and unreadable"

But I've no idea what to do about that, or even if anything can be done.

The Windows 11 VM was built by way of free upgrade from a running Windows 10 VM clone in VirtualBox 7.0.4, and I have to say the result has been a bit flakey in parts, especially in MS Office apps, within which I've had to disable hardware acceleration by editing the Registry.

For a number of highly circumstantial reasons that I won't go into here I wonder whether the problem(s) might be something to do with the openSUSE implementation of 7.0.4 and/or a flawed installation of Guest Additions. But that's all well beyond my level of understanding and I'm only guessing.

[RobinK]

.vbox file attached, as requested

[fth0]

The Windows 11 VM was built by way of free upgrade from a running Windows 10 VM clone in VirtualBox 7.0.4

a flawed installation of Guest Additions

Those two quotes make a story: When upgrading Windows on the host, in some cases VirtualBox had to be reinstalled to make its drivers work again. The same might hold true in the guest, because the VirtualBox Guest Additions (GA) also installed drivers. Therefore, I'd suggest to repeat the GA installation.

[RobinK]

The Windows 11 VM was built by way of free upgrade from a running Windows 10 VM clone in VirtualBox 7.0.4

a flawed installation of Guest Additions

Those two quotes make a story: When upgrading Windows on the host, in some cases VirtualBox had to be reinstalled to make its drivers work again. The same might hold true in the guest, because the VirtualBox Guest Additions (GA) also installed drivers. Therefore, I'd suggest to repeat the GA installation.

I've tried re-installing the GA multiple times, without result.

But things get curiouser and curiouser. I still have the original Windows 10 VM, now in VirtualBox 7.0.4. I fired it up and Lo! the (same) shared folder works perfectly. Which probably doesn't do much for my theory of a faulted implementation of VBox 7.0.4. Rather, it would suggest something's wrong within the Windows 11 VM itself.

[RobinK]

I've tried re-installing the GA multiple times, without result.

OK; for what it's worth I now have a result.

The multiple re-installs of GA referred to above had all been done on top of what was already there. I thought to try again, but this time after deliberately un-installing the GA component already there. And it worked - I now have my shared folder back.

Should have thought of that before .....