Automount of shared folder does not work when saved state is restored

[Racoon]

Hello,

I am using Windows 10 as host and Lubuntu 18.10 as guest.

After I start the guest system, the shared folder is properly available. Once I save and restore the state of the guest system, the folder has disappeared.

Only when I shut down the guest and start again, the folder is available again.

Settings: automount and permanent

[Socratis]

1. I can't reproduce it on an OSX 10.11.6 host with a Mint 19 (based on Ubuntu 18.04) guest.

2. It's usually better and faster, if issues get first addressed in the ​VirtualBox forums, a lot more eyes there. More than 95% of the issues are resolved over there, which keeps the developers focusing on the bug fixes and enhancements, and there is no need for another ticket to keep track of.

3. You were supposed to follow these steps when you filed the bug, and provide a VBox.log:

   Attach a (full) log file ("Machine" menu/"Show Log" in the main VirtualBox Manager window) straight away to save time for you and for us. The log file contains a lot of useful information about both the host and the guest systems as well as information about what happened during a particular machine run. Please do not cut and paste it.
   

[Racoon]

Try it several times in series (save state then restore state).

After the first time, it seems to work for me as well. But after the second time, the folder is no longer mounted. Funnily, after the third time, the folder was mounted twice: sf_(name) and sf_(name)_1

[Socratis]

Well, post the logs from a failed state and we'll try to see what's going on...

[Racoon]

VBox.log is the file without mapping and VBox.log.3 is the one where was mapped twice

[Armando]

I'm also experimenting this issue since installing VBox6. I haven't found yet any way to recreate it "on demand", so at the moment the behaviour seems casual to me.

Sometimes, after starting a VM from a saved state, the shared folders are still there as expected, other times they appear in... multiple instances, other times they are not present at all. In the latter case, to be more precise, they still appear in the VM's shared folders settings dialog, but they are not connected to the VM. This seems to affect both my Windows and Linux guests (host Win10 64). In a Windows 8 guest the shared folder just does not appear in "\ \vboxsvr", while in Linux (Ubuntu18 64) the mounting is broken (umount is impossible and sometimes also the mount-point folder gets deleted) and any attempt to re-mount the folder produces a "mounting failed with the error: Protocol error" message.

Fortunately the connection can be easily re-established, with no need to restart the VM, by deleting/recreating the shared folder (or even by just editing it in any way) inside the shared folders settings dialog. So the problem is not actually serious, although obviously a bit annoying.

[Racoon]

Replying to Armando:

Fortunately the connection can be easily re-established, with no need to restart the VM, by deleting/recreating the shared folder (or even by just editing it in any way) inside the shared folders settings dialog.

thank you, this workaround also works for me

[simonis]

I also have this problem with VB 6.0.2, Windows 10 host and Ubuntu 14.04 guest. Workaround works for me as well, but it would be nice to get this fixed :)

[JakubKlos]

I can confirm this issue on VBox 6.0.2 as well. Host is Ubuntu 18.04 and guest is also Ubuntu 18.04. Most of the time it stops working after each restore of the saved state. Occasionally, it worked from scratch. It also happens on my Windows 7 guest.

I use the trick with changing the Shared Folders information to restore the connection as mentioned above. It works but it is slow obviously.

The strange part is that when I use the "VBoxControl sharedfolder list" it gets a duplicated list of all folders. It happens on both Windows and Ubuntu guests. Sometimes even reboot does not help and I need to do the Shared Folders settings change trick.

$ ./VBoxControl.exe sharedfolder list
Oracle VM VirtualBox Guest Additions Command Line Management Interface Version 6.0.2
(C) 2008-2019 Oracle Corporation
All rights reserved.

Shared Folder mappings (15):

01 - Downloads [idRoot=0 writable auto-mount host-icase mnt-pt=Y:]
02 - Repository [idRoot=1 writable auto-mount host-icase mnt-pt=X:]
03 - media [idRoot=2 writable auto-mount host-icase mnt-pt=Z:]
04 - Downloads [idRoot=3 readonly host-icase mnt-pt=Y:]
05 - Repository [idRoot=4 readonly host-icase mnt-pt=X:]
06 - media [idRoot=5 readonly host-icase mnt-pt=X:]
07 - Downloads [idRoot=6 readonly host-icase mnt-pt=Y:]
08 - Repository [idRoot=7 readonly host-icase mnt-pt=X:]
09 - media [idRoot=8 readonly host-icase mnt-pt=X:]
10 - Downloads [idRoot=9 readonly host-icase mnt-pt=Y:]
11 - Repository [idRoot=10 readonly host-icase mnt-pt=X:]
12 - media [idRoot=11 readonly host-icase mnt-pt=Z:]
13 - Downloads [idRoot=12 readonly host-icase mnt-pt=Y:]
14 - Repository [idRoot=13 readonly host-icase mnt-pt=X:]
15 - media [idRoot=14 readonly host-icase mnt-pt=X:]

Should you need more information I will gladly provide it

[j00n]

Dear VBox team,

I just wanted to confirm as well: I am having the same issue with Linux (Ubuntu) as Host and Linux (ArchLinux) as Guest. I am working with snapshots and restore them from time to time. As soon as I did the second or more snapshot and restore the last state the sharedfolders won't get remounted. For me, the only option is to completely reboot the guest-VM. I cannot even force unmounts, remounts or simple mounts due to errors.

Kind Regards, Marion 'j00n' Jaeger

[Socratis]

Sounds like #18373

I wouldn't know which has more information about the issue, but there's also a discussion in the forums: ​https://forums.virtualbox.org/viewtopic.php?f=2&t=91420

[waldner]

Same problem here with Linux host and windows guest (6.0.4 r128164 on both).

[g2flyer]

FYI: same problem with Win8.1 host and ubuntu 18.04 guest on 6.0.4, 6.0.2 (and probably 6.0.0)

[pilchkinstein]

Shared folder disappearance also with:- Host: Win10 Guest: Ubuntu 18.04 LTS VBox: 6.0.4 r128413 win.amd64

I dont know what to look for in the log to help but will happily send if required. From my observation this doesnt even need a restore from saved state, it just happens about once a week. I have once managed to restore the shared folder by saving machine state then starting again but today (2019-02-25) that isnt working. My setup is a single shared folder set to automount and permanent. I have enabled symlink creation in that folder within the host.

Happened again (2019-03-01) tried deleting shared folder, editing, renaming etc but none of this works for me so having to reboot.

[lorenzosu]

This also happens to me with permanent shared folders when re-opening a saved state with:

• Linux Host (VirtualBox 6.0.2 Oracle - Manjaro 64bit)
• Windows 7 and Windows 10 guests both with Guest Addon versions up to 6.0.2

What happens in the Windows guest is that the shared folders either show up as 'network drives' but are not accessible (and not shown in the VBOXSVR network group), or disappear all together. Rebooting *sometimes* solves the problem, otherwise the shared folders need to be deleted and re-added from the Shared Folders Settings. This behaviour started with VirtualBox 6 update.

Lorenzo.

[Andreas-P]

Just to add my same-here:

Since 6.x, now running 6.0.4 on macOS 10.14.3, my Debian9 and Windows10 VMs with 6.0.4 vbox tools show the issue mentioned above: shared folders unavailable after restore, will reconnect when modified in the shared folder dialog.

[ThomasJammet]

I have the same bug here since I have installed VirtualBox 6 (6.0.4 is my current version) on my Windows 10 host. This happens on all my old fedora guests, I have also built a new Fedora 29 guest but there is always the same issue :

• When I start the guest and then run the following command :

mount -t vboxsf SomeDir /home/user/SomeDir/

• It works fine, I can access to the SomeDir directory
• Then if I pause the guest and launch it again the directory is not available anymore and with the "ls -al" command I see "?" instead of the directory attributes.
• To have access to this directory again I have to go to the "Shared Folders" window and change any input ("Auto-mount" for example), then strangely the directory icon appears in the "Folder Path". I click "OK" and try to mount again the directory with the command above and finally I can access to the directory again.

This is quite painful and I am starting to think switching back to VirtualBox 5.

[arstrube]

I am having the same problem with MacOs Mojave host and Windows XP client. Same as Racoon, the only remedy is to restart the client.

I also had the duplicate folders problem mentioned above. That went away when I specified the mount points as the desired Windows drive, e.g. A:, F: etc.

[karolbe]

Same issue here, Linux as the host, Windows 7 as the guest. VBox 6.0.4 r128413 (Qt5.12.0), the latest Guest Additions are installed.

[lorenzosu]

I wonder if there's any progress on this. It makes Windows gusts very unusable and in particular saved state, as I'm essentially forced to shut-down and restart the VM each time to restore shares.

[mau17]

I have the same problems everyone else has discussed. My system is:

host: Ubuntu 14.04 guest Windows 7 Virtualbox 6.0.4 r128413 (Qt5.6.1) with guest additions installed.

I appreciate the efforts you put in this great software, but this bug greatly affects its functionality. Every important file I use is in a shared folder.

Thanks

[Socratis]

Replying to mau17:

but this bug greatly affects its functionality. Every important file I use is in a shared folder.

Two things:

1. there's a known workaround, as in not using saved states. And please don't tell me that a minute to shutdown the VM's OS properly is "affecting the functionality". Think of how you treat your physical computer.
2. Don't rely solely on shared folders, you might be in for surprise bugs. If you heavily depend on shared files, see if you can use a traditional method of connecting your host and your VM, SMB (Windows) shares for example. And backup! ;)

[g2flyer]

Replying to socratis:

1. there's a known workaround, as in not using saved states. And please don't tell me that a minute to shutdown the VM's OS properly is "affecting the functionality". Think of how you treat your physical computer.

Not 100% convinced about this argument: i suspend and hibernate my laptop all the time. It's not only the time of the reboot but also the time for restoring all the environment/setup you had. Windows shares could be an alternative but then VB shared folder were convenient and worked well prior to VB6 ....

[Socratis]

Replying to g2flyer:

Not 100% convinced about this argument: i suspend and hibernate my laptop all the time. It's not only the time of the reboot but also the time for restoring all the environment/setup you had.

I'm not saying it's not a bug. I'm saying use this workaround (I mentioned it's a workaround) until this is addressed. That's as far as "it greatly affects its functionality" comment. Yes it does, but there's a workaround. Would it be better if there wasn't one? ;)

[jasonh]

I really appreciate VB; it is/has been rock solid and something I rely on every day.

I especially rely on/liked the suspend/resume functionality, since restoring to a previous working state is a great timesaver.

This regression in VB6 though is maddening and something I hope is being treated as a high priority (I can't tell from the ticket)?

A workaround would be something, but going into "Shared Folders" and changing something doesn't necessarily work. I have 3 shares (Linux host, Windows guest), and if I change something for share #1 say, then share #2 might be the one which starts working again.

[Socratis]

Replying to jasonh:

This regression in VB6 though is maddening and something I hope is being treated as a high priority (I can't tell from the ticket)?

Historic fact: there used to be a priority field up until recently, but it got taken out. Because people were fighting, thinking that their bug was the topmost priority one! :)

As another user, I can tell you that if it doesn't involve data loss, and if there's a really easy workaround that just inconveniences the end-user, personally I would definitely not put it as a high-priority one.

Having said that, 6.0.6 just came out and per the Changelog:

• Shared folders: fixed duplicate folders after restoring a saved state (bug #18373 and other)

Not sure if the "other" involves #18220 as well, give it a shot and let us know...

[yaap]

Looks good with 6.0.6 on Debian Buster with W10 guest. The issue was systematic on suspend, now after a handful of suspend/resume cycles all is working fine. So it's just a quick test, but maybe enough for others to give it a try.

[Racoon]

As of version 6.0.2, shares are no longer automatically mounted in Lubuntu. I have uninstalled and installed VirtualBox Guest Additions a few times with no error messages. Only Guest Additions 6.0.0 works.

[FredO6]

Had similar problem here (dmesg on Linux guest says: sf_read_super_aux err=-71), but it was fixed after 6.0.6

[bird]

As for 6.0.8+ I'm not entirely sure whether or not there are still open issues here, so I'll close it for now and if someone still have issues please reopen, attach a VBox.log file and describe the troubles clearly.

[Johny Why]

My shared folder isn't getting auto-mounted when i reboot the guest.

Running archlabs linux on Windows 10 with VirtualBox Version 6.0.14 r133895 (Qt5.6.2)

According to arch wiki, I installed virtualbox-guest-utils and xf86-video-vmware, "for the default linux kernel choose virtualbox-guest-modules-arch". ​https://wiki.archlinux.org/index.php/VirtualBox#Install_the_Guest_Additions

i am getting shared clipboard no problem.

The shared folder mounts when added manually (with vbox shared-folder wizard) no problem.

[Socratis]

@Johny Why

The discussion should continue in the thread that you opened in the forums: ​https://forums.virtualbox.org/viewtopic.php?f=3&t=95472

As I told you already in the thread, you need to follow the official instructions for installing the Guest Additions, not any 3rd party site, no matter how reputable they might be...