[Vbox 6.0] Shared Folders Randomly Stop Working

[jimnms]

After updating to Virtualbox 6.0, everything seemed to be fine. After saving and restoring a VM, the shared folders would not always restore with it. Trying to manually re-mount them would give an error about no such directory. They would work again after restarting the VM, but they would randomly stop working again after saving and restoring a VM.

Today, I can't get shared folders to work at all. I restarted the VM, but the shared folders won't auto mount or mount manually. I downgraded back to 5.22, and even with the 6.0 guest additions still installed, shared folders are working again. I checked the log file and didn't see any errors.

[socratis]

You didn't tell us the host, the guest or any other details. We need to see a complete VBox.log, from a complete VM run, where the problem occurs:

• Start the VM from cold-boot (not from a paused or saved state) / Observe problem / Shutdown the VM (force close it if you have to).
• With the VM completely shut down (not paused or saved), right-click on the VM in the VirtualBox Manager and select "Show Log".
• Save only the first "VBox.log", ZIP it and attach it to your response. See the "Upload attachment" tab below the reply form.

[jimnms]

Sorry, I didn't save a log before reverting to 5.22. It appears the problem goes deeper than the shares, but it may be related. I decided to re-install 6.0 today and see if I could re-produce the problem. As usual, the shares were working at first boot, however, after about 30 minutes, I began to notice odd behaviors. I first noticed when I would copy something to the clipboard on the VM, it sometimes wouldn't transfer to in the host OS's clipboard. It would take several tries to get the clipboard to copy over. Then the VM began to respond very slowly. I was writing a lot to one of the shared folders. At one point I thought the VM had frozen, but I was still getting disk activity. I have Process Hacker running on the host OS, so I checked the disk activity tab and I could see it was still writing to the shared folder. Once the writing to the shared folder finished, the VM became somewhat responsive again. Even though everything in the VM was idle, there was still a lot of disk activity. Process Hacker showed a lot of read/write activity to the VM's .vdi file, and the VM was very sluggish. I managed to close everything and perform a normal shutdown, which took several minutes.

The entire session was only about an hour long from boot to when I had to shut down. I didn't even get time to re-produce the shared folder problem from before. I have attached the log file from the session. This did happen previously before I reverted back to 5.22, but I didn't think much of it at the time since I had saved and restored the VM state a few times.

Since the problem goes beyond my initial post, should I rename the original topic or start a new post?

[socratis]

I told you to follow a specific procedure to get the log. For example:

Start the VM from cold-boot (not from a paused or saved state)

00:00:04.019485 Changing the VM state from 'CREATED' to 'LOADING'
00:00:04.019787 SSM: File header: Format 2.0, VirtualBox Version 6.0.0 r127566, 64-bit host, cbGCPhys=8, cbGCPtr=8
00:00:04.020980 SSM: Saved state info:

As for the title and the scope of the thread: if this is a one-off, don't bother. For example, your host may have been low on resources, something that can't be seen in the logs.

And as for the clipboard, just remember that only simple text makes it through: Notepad to Notepad, gedit to gedit...

[jimnms]

I did not start it from a paused or saved state. I had to restart the VM for an update anyway, so I shut it down and decided to give 6.0 another try. After I updated from 5.2.22 to 6.0, I started the VM, and everything in the log was from the first boot to the shutdown. That was the only log from 6.0, the other logs were previous logs from 5.2.22.

For example, your host may have been low on resources, something that can't be seen in the logs.

The host clean booted this morning and was not low on resources. After the problems with 6.0 again, I reverted back to 5.2.22 and used the VM for the rest of the day without problems, so this is only happening with 6.0.

And as for the clipboard, just remember that only simple text makes it through: Notepad to Notepad, gedit to gedit...

Text is all I was copying. Instead of copying, it seemed to clear the clipboard. When it did successfully copy to the clipboard, the next time I tried to copy something the clipboard would be empty. If it was just failing to copy, the previous text should still have been in the clipboard instead of empty.

[jrc55]

I have seen a problem similar to the one seen by jimnms. But not the exact same. I do have a work-around.
Host Win 10 Home current version.
Guest Fedora 29 KDE spin.
Intel i7-6700 - 16 gb memory on the machine - 4 gb allocated to the guest
My problem is not an intermittently working shared folder, but one not working at all. I noticed it starting with kernel 4.9.12. But I resolved it by upgrading the kernel separate from the other modules that were available for upgrade at that time. I could upgrade those other modules before or after the kernel modules, but not at the same time. Don't ask me why. It doesn't make sense to me either. But I use snapshots and when the problem occurred I restored the snapshot and began installing modules piecemeal until I isolated it to the kernel. My work-around worked when the kernel was upgraded to 4.9.13 and the recent 4.19.14 too. It was happening with VBox 5.2.22 and even after the upgrade to VBox 6.0.2 it was broken again, but there was a kernel 4.19.14 available and after an upgrade to it (and reboot) the problem went away again.

Maybe this will make sense to someone.
Hope this helps.
John

[Air Force One]

@jimnms: Is this something like ticket 18151?

[SavedStates]

In my case, a new Ubuntu18 guest running on Win10 host would not show the mapped permanent shared folder inside the guest. Was driving me nuts so I took a look at the log file and saw this ...

Code: Select all   Expand viewCollapse view

00:12:41.371613 GUI: UIMachineLogicNormal::sltCheckForRequestedVisualStateType: Requested-state=0, Machine-state=5
00:12:41.499296 VMMDev: Guest Log: 12:31:17.882523 main     VBoxService 6.0.6 r130049 (verbosity: 0) linux.amd64 (Apr 16 2019 11:55:19) release log
00:12:41.499323 VMMDev: Guest Log: 12:31:17.882527 main     Log opened 2019-05-11T12:31:17.881945000Z
00:12:41.499370 VMMDev: Guest Log: 12:31:17.882613 main     OS Product: Linux
00:12:41.499402 VMMDev: Guest Log: 12:31:17.882647 main     OS Release: 4.18.0-18-generic
00:12:41.499430 VMMDev: Guest Log: 12:31:17.882675 main     OS Version: #19~18.04.1-Ubuntu SMP Fri Apr 5 10:22:13 UTC 2019
00:12:41.499457 VMMDev: Guest Log: 12:31:17.882702 main     Executable: /opt/VBoxGuestAdditions-6.0.6/sbin/VBoxService
00:12:41.499466 VMMDev: Guest Log: 12:31:17.882702 main     Process ID: 1534
00:12:41.499472 VMMDev: Guest Log: 12:31:17.882703 main     Package type: LINUX_64BITS_GENERIC
00:12:41.500350 VMMDev: Guest Log: 12:31:17.883594 main     6.0.6 r130049 started. Verbose level = 0
00:12:41.505316 GUI: UISession::sltAdditionsChange: GA state change event came, notifying listeners
00:12:41.505349 GUI: UIMachineLogicNormal::sltCheckForRequestedVisualStateType: Requested-state=0, Machine-state=5
00:12:41.510814 VMMDev: Guest Log: 12:31:17.894037 main     vbglR3GuestCtrlDetectPeekGetCancelSupport: Supported (#1)
00:12:41.512033 ASSERT_GUEST_LOGREL F:\tinderbox\win-6.0\src\VBox\HostServices\GuestControl\VBoxGuestControlSvc.cpp(1119) int __cdecl GstCtrlService::clientMakeMeMaster(struct ClientState *,struct VBOXHGCMCALLHANDLE_TYPEDEF *,unsigned int): fRequestor != VMMDEV_REQUESTOR_LEGACY
00:12:41.512056 Outdated VBoxGuest w/o requestor support. Please update!
00:12:41.514610 VMMDev: Guest Log: 12:31:17.897852 main     Error: Failed to become guest control master: VERR_VERSION_MISMATCH
00:12:41.515882 VMMDev: Guest Log: 12:31:17.899131 main     Error: Service 'control' failed to initialize: VERR_VERSION_MISMATCH
00:12:41.515981 VMMDev: Guest Log: 12:31:17.899235 main     Session 0 is about to close ...
00:12:41.516013 VMMDev: Guest Log: 12:31:17.899266 main     Stopping all guest processes ...
00:12:41.516049 VMMDev: Guest Log: 12:31:17.899302 main     Closing all guest files ...
00:12:41.516064 GUI: UISession::sltAdditionsChange: GA state change event came, notifying listeners
00:12:41.516082 GUI: UIMachineLogicNormal::sltCheckForRequestedVisualStateType: Requested-state=0, Machine-state=5
00:12:41.516132 VMMDev: Guest Log: 12:31:17.899342 main     Ended.


The VERR_VERSION_MISMATCH error made no sense because I installed the latest VB6.0.6 and guest additions for it and everything else I would expect, such as screen resizing, was working fine. But that error lead me to run the guest additions CD inside the guest again and have a closer look at what it reported.

I don't have a screenshot, but turns out the guest additions inside the guest reported that it could not build on the guest and needed "gcc perl make" installed. This was only clear when I took the time to read all the messages in the console.

Ran sudo apt-get install gcc perl make and then restarted and then reran the guest additions inside the guest.

Presto, my shared folder now shows up.

Hope this helps someone.