Widespread VirtualBox Shared Folders breakage with [Stable Update] 2019-01-17



At least here on MacOS host, it is NOT the full path, but just the name of the directory.
In my case, the absolute path would be /Users/username/VBox, but in the mount command I only use VBox.
The mountpoint however seems to take an absolute path.

Output of mount:
VBox on /mnt type vboxsf (rw,relatime)


Hmmm, i didn’t expect [The Spanish Inquisition] this duplication:

~ >>> mount                                                                     
SHARE_Folder on /media/sf_SHARE_Folder type vboxsf (rw,nodev,relatime,uid=0,gid=109,ttl=0,dmode=0770,fmode=0770,dmask=00,fmask=00,tag=VBoxAutomounter)
VM_Share_Folder on /media/sf_VM_Share_Folder type vboxsf (rw,nodev,relatime,uid=0,gid=109,ttl=0,dmode=0770,fmode=0770,dmask=00,fmask=00,tag=VBoxAutomounter)
temp_(Seagate) on /media/sf_temp_(Seagate) type vboxsf (rw,nodev,relatime,uid=0,gid=109,ttl=0,dmode=0770,fmode=0770,dmask=00,fmask=00,tag=VBoxAutomounter)
SHARE_Folder on /media/sf_SHARE_Folder_1 type vboxsf (rw,nodev,relatime,uid=0,gid=109,ttl=0,dmode=0770,fmode=0770,dmask=00,fmask=00,tag=VBoxAutomounter)
temp_(Seagate) on /media/sf_temp_(Seagate)_1 type vboxsf (rw,nodev,relatime,uid=0,gid=109,ttl=0,dmode=0770,fmode=0770,dmask=00,fmask=00,tag=VBoxAutomounter)
~ >>>  

Maybe it means that one of those previous manual mounting methods i tried [which appeared to fail given the error messages] kinda sorta half-worked? Presumably one suite of these mounts are those coming from my deliberate installation of the service from the ISO… but t’other?

Sorry to be such a thickhead, but are you saying i should be able to [in the Guest] use literally just the relative directory name, NOT need the full/absolute path… for BOTH parts of your command [ie the host part AND the guest part]?

EDIT: Stupid dopey @kdemeoz - of course it does not mean that… they all show /media/..., & ONLY my ISO-installed service does that. Those earlier manual mount attempts used different mount points. So the duplication puzzles me still.


Wait… so you have the automount option enabled? I haven’t tested this yet, give me a sec.

Lemme explain the setup I have here:
MacOS host: the absolute (complete) path of the folder I want to share is /Users/username/VBox
Manjaro guest: the mountpoint where I want the share to be mounted on is /mnt

In the guest, I mount with mount -t vboxsf VBox /mnt
So the name of the share is the folder itself, here: VBox, not the complete path.
The mountpoint however is the complete path on the guest.

EDIT: automount doesn’t work here.


Well, yes, i’ve done it this way for years, & historically this was always a doddle, worked a treat. Recently though, not so much…

So, why i now have this duplication is an additional bafflement for me:

kdemeoz@manjaro-ob-vm Linux 4.19.14-1-MANJARO x86_64 18.0.2 Illyria
/media >>> ls -la                                                               
total 32
drwxr-xr-x  7 root root   4096 Jan 22 20:02  .
drwxr-xr-x 18 root root   4096 Jan 22 16:27  ..
drwxrwx---  1 root vboxsf 4096 Mar 12  2018  sf_SHARE_Folder
drwxrwx---  1 root vboxsf 4096 Mar 12  2018  sf_SHARE_Folder_1
drwxrwx---  1 root vboxsf 4096 Jan  1 18:11 'sf_temp_(Seagate)'
drwxrwx---  1 root vboxsf 4096 Jan  1 18:11 'sf_temp_(Seagate)_1'
drwxrwx---  1 root vboxsf 4096 Jan  1 18:11  sf_VM_Share_Folder
/media >>>


I’ll have to check this later today when I have access to a Manjaro host.

In your 1st screenshot, you can see the names of the shares in the first column. That’s the name you would use in the mount command.


Ta. In my Guest i now did:

/media >>> sudo mount -t vboxsf SHARE_Folder /mnt                            [1]
[sudo] password for kdemeoz: 
/media >>>

Then in the file manager i tried to access this directory, but NFG:


Should i have rebooted the VM first? Or, likely maybe i need to grant myself permission…

Maybe there’s a conflict coz this folder is already being shared [per previous posts above]?


Yes, check permissions of the (mounted) mountpoint - however, even if /mnt belongs to root, it should at least have read permissions for everyone…

Maybe it would be a good idea to start from afresh?

EDIT: see strikethrough above, I think you do have to set permissions, I can see the content of /mnt but I cannot open the files in it.


I switched to this approach and works flawlessly + the rw ability from the guest … :slight_smile:


Hearty thanks for your generous help. It’s my 21:20 & i’m frazzled [bet you can’t tell…], so i shall pick up the cudgels again on this tomorrow . Now it’s time for stir-fry & NF. Ta - it’s good night from her & it’s good morning to him. :stuck_out_tongue_winking_eye:


That’s exactly what I wanted to write… :slight_smile: that should work!

Good night, I’m 10 hours behind.

EDIT: I confirm, Bogdan’s hint solves the permissions issue.



The annoying / disappointing thing is, that this was explicitly one of my attempts, hours ago… see my earlier

However, when i retried it again now…

~ >>> sudo mount -t vboxsf -o uid=1000,gid=1000 SHARE_Folder /mnt               
[sudo] password for kdemeoz: 
~ >>>

… given both your assurances / assertions, it DOES now work for me too. Presumably my earlier attempt was thwarted by me stuffing up my syntax for the share, &/or the mount. Yippee. Tomorrow, in this Test VM, i’ll remove the superfluous vbox service [which came from the ISO], disable the corresponding systemctl unit, remove the VBox GUI Shared Folders stuff, then repeat this latest step for each of my desired Shares. If that succeeds & survives a few cycles of VM starts/stops/sleeps, i’ll replicate the process on all my other Manjaro Guests.

Thank you, inestimable Manjaroos Of A Northern Hemispherical Persuasion! [dog i’m peckish now!].

PS: A Special Thank You to @sueridgepipe for their OP solution !!!


I’ve been using this approach for as long as I’ve been running Manjaro, it is rock solid, reliable, 2 way, and you only mount your SF when you need them in each VM.

If you have multiple SFs then just create extra aliases.


I have not been ignoring your old advice. I did try it. Clearly though i stuffed it up. I seem to be talented in that department.


I understand, my comment was more about its reliability, not your adoption of it.


Oh tis all just such fun. Today:

These steps seemed successful:

  1. Absolutely definitely ensure that this is done; VirtualBox 6 slow start/shutdown
  2. Reboot the VM [unsure if mandatory, but take no chances].
  3. I tried again applying this method of manually mounting my SFs in my VMs; Virtualbox not automounting shared folder in guest (Manjaro KDE v18.0.2) , but initially i presumed this must have been intended to be independent of, hence not need, setting the SFs in the VirtualBox Manager GUI Settings, so i removed them all, only to discover that’s hopeless:
kdemeoz@manjaro-ob-vm Linux 4.19.14-1-MANJARO x86_64 18.0.2 Illyria

~ >>> sudo mount -t vboxsf -o uid=1000,gid=1000 SHARE_Folder /mnt               
[sudo] password for kdemeoz: 
/usr/bin/mount.vboxsf: mounting failed with the error: Protocol error

~ >>> alias vbmount2='sudo mount -t vboxsf -o uid=1000,gid=1000 SHARE_Folder /home/kdemeoz/SharedFoldersMount/'
~ >>> vbmount2                                                                  
[sudo] password for kdemeoz: 
/usr/bin/mount.vboxsf: mounting failed with the error: Protocol error
  1. So then i used the VB Manager GUI to again set [initially just one of my Host’s SFs] SHARE_Folder to be a Shared Folder, but unlike my historic practice, now i marked it for NEITHER AutoMount nor Permanent. Thereafter the manual mounting worked, & i had proper access to all contents.
  2. I confirmed that this SF did NOT survive VM reboots, ie, each time the manual mount command had to be reissued in terminal.
  3. I then reflected on the apparent pointlessness of needing to access my SF via this manual method, given that the method fails unless i’ve already done Step #4… but if i must do that step anyway, why tie one arm behind my back afterwards by not also using the inbuilt AutoMount & Permanent settings? In retrospect this just seems silly. Furthermore, this Wiki [Wiki][VirtualBox] Installation, USB devices and Shared folders specifically says:

VirtualBox host
Setup the shared folder(s)
On the host locate the Settings section in VirtualBox GUI.

Make the folders Permanent and Automount.

  1. So i chose to re-enable both those settings.
  2. Tests subsequently confirmed that this SF correctly survived 2 VM reboots, & also a VM Close - Resume cycle.
  3. This obviously sounds like the perfect solution, providing all of:
    1- No artificial delay during VM SU & SD caused by, since VB v6, each VM SD/reboot taking several minutes whilst the vboxadd.service was being stopped, & then every SU similarly taking ages whilst that service was being started
    2- My Host’s SFs available automatically in Guest’s /media directory.
    3- Said SFs surviving VM Close - Resume cycles.
    4- No need for the manual command faffing about each time.
  4. However, i had ALREADY arrived at this apparent solution back on 17/1 [per my VirtualBox 6 slow start/shutdown], BUT it all ■■■■■■ up again only a day later on 18/1 & 20/1 [per my Widespread VirtualBox Shared Folders breakage with [Stable Update] 2019-01-17], ie, this very thread’s OP]. In other words, it feels like i’ve simply gone around in circles.
  5. Why therefore should i feel confident that today’s progress won’t also be unwound with future Manjaro updates???

Ohhhh… my brain hurts!


(Sound of birds singing and then knock on door)

Michael: Come in!

(Sound of someone crashing through the door)

Michael : Oh, open the door and come in!

John : Sorry…

Michael : Hello!

Eric : Sorry!

Michael : Shut up!

John : I’ve got my head stuck in the cupboard!

Eric : Sorry!

Michael : Shut up!

John : I can’t see anything!

Michael : Hello!

John : I can’t see anything!

John : Hello!

Eric : Shut up, Mr Gumby!

(sound of glass breaking)

John : Ohhhh… my brain hurts!

Michael : Shut up!

John : Sorry!

Eric : Ooohhhhhh…

Eric Idle : (As an announcer) meanwhile in St Petersburg Illya Nataevska and Mariana Plaentkoff await news of their step-brother Troffemoff…

Michael : Hello!

(sound of more glass breaking)

Michael : Oh I have broken it!

John : Get off my foot!

Michael : Shut up!

John : Sorry, my brain hurts! My Brain hurts!



That indeed seems troublesome - I can relate to brain hurting - especially when everything seems to be running in circles.


Your guest VMs sound like an absolute mess, so much troubleshooting and a plethora of different changes applied and removed over time.

None of my guest VMs have the vboxadd service, with the Manjaro guest utils and guest extramodules packages the vbox additions are not required.

Of course you have to setup shared folders to access a shared folder, how else would it work? The manual mount is only a workaround for the automounting not working.

Also, no manual mount will survive a reboot either. This is true for any system, bare metal or virtual. This is what fstab is for.

The process is so simple. Create a shared folder in VM settings, make it permanent, manually mount it in the VM when needed, manually umount it when done.

I fail to see how it keeps breaking, my shared folders have been working fine for years.

Do your shared folders in VM settings disappear? Can’t say that has ever happened to me, outside of exporting a VM to a different host system.

Or did the automount simply stop working?



I’ve been waylaid by some completely unrelated matters, so have not yet been able to properly continue this rotten problem investigation All i can tell you is that today to my severe-pissed-off-ness i discovered that one of my VMs in which i finally managed to get my SFs to work, via your manual mount method* 2 nights ago, then Suspended the VM til today, now not only has non-functional SFs simply from VM Resume, but worse, even after rebooting said VM the bloody SFs still refuse even to be manually mounted now [error message saying the mount point does not exist, despite the fact that it is plainly visible still in the file manager… & my threats of violence & sarcasm at it strangely also don’t help].

*coz like all my other Manjaro VMs since v6 the VB SF Automount function is utterly stuffed (symptoms include any of these, depending on time of day, day of week, & wind direction; SFs in the VM’s file manager vanish / don’t vanish but deny access / allow access but are empty).

I’m once again not likely to have spare time to return to this for a day or three, but in the interim, i have a question for you pls. In all your Manjaro Guests, if you check the session info, what does it tell you for the VB GA version? In my case, since VB v6, 100% of my Manjaro VMs wrongly say this:



Yes, I have 5.2.0 here too… No idea why though.

EDIT: well it could be that the vboxguest module is actually the in-tree kernel module (CONFIG_VBOXGUEST=m in kernel config), since it has a valid signature.
So it’s not part of the extramodules (linuxXXX-virtualbox-guest-modules).
Only vboxsf for shared folders is an extramodule.

Here’s the answer, kernel 4.19:

 * VBox Guest additions version info, this is used by the host to determine
 * supported guest-addition features in some cases. So this will need to be
 * synced with vbox upstreams versioning scheme when we implement / port
 * new features from the upstream out-of-tree vboxguest driver.
/* Last synced October 4th 2017 */
#define VBG_SVN_REV 68940
#define VBG_VERSION_STRING "5.2.0"

So nothing wrong, it is what’s being used in the kernel source, which vboxguest is a part of.


Yeah, that’s not a phrase that passes my lips much these days, wrt VM SFs… :wink: Ta.