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

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.

1 Like


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 !!!

1 Like

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.

1 Like

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 [HowTo] VirtualBox - Installation, USB, 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.

1 Like

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.

1 Like

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


By the way, my shared folders appear to be working fine after the last update.

I posted in the other thread ([Stable Update] 2019-01-17 - Kernels, KDE Apps, KDE Plasma, Deepin, Firefox, Calamares, XFCE), but perhaps it is more relevant here.

I can confirm the breakage of shared folders. I do have a vastly more simple use-case with fewer moving parts (Win 7 guest on Manjaro Host) which worked perfectly on 5 but is broken on 6, meaning no need for changes on the guest (except for installing Guest Additions).

I successfully downgraded VirtualBox back to 5.2.22 (complete downgrade instructions are in my post) and got folder sharing working again.

If anyone has a suggestion for something to try to get folder sharing to work on VirtualBox 6, I'm all ears.

Which kernel are you using on the host?

On my laptop I use 4.14 and on my desktop 4.19. I only tested this on my laptop for now.

Yeah i did see your earlier post, but [no offence] i do not wish to backtrack to 5.x coz that then brings back other issues.

How do we reconcile your v6.0.2 [in the picture] with:


Every one of my Manjaro VMs now has broken SFs. Every one of my non-Manjaro VMs continues to have working SFs. Gahhhhhhhhh. There's something systemic here at my end, but so far i'm failing to uncover it.

It's possible that he doesn't use the in-tree vboxguest module, but the one that comes with the VBox Guest Additions.
I don't think it has an influence on shared folders though (vboxsf is out-of-tree).

1 Like

Well, I only run Windows guests, so maybe that's part of the problem.

Yes, I'M not sure if it comes from virtualbox-guest-iso or virtualbox-ext-oracle though.

Have you installed vbox additions on all your Manjaro systems?

If so maybe install a control test Manjaro VM without vbox additions?

I have never installed vbox additions with Manjaro guests, only the kernel guest extramodules and guest utils package, and my SFs always seem to work.

If by that you mean have i run this command in each of my older Manjaro VM's... sudo ./VBoxLinuxAdditions.run... then the answer is almost certainly yes. I do not have a sane leg to stand on here to defend myself... when i initially migrated to Manjaro i did not know what i did not know [damn Rumsfeld], & hence once i later began creating Manjaro VMs in my now-Manjaro Host, being indefensibly ignorant of the Wiki i simply used the method that was tried & true historically for all my older VMs, which included by definition running that command in each VM as part of setting up the SFs. By the time i later discovered that Manjaro VMs are different, i presume i had already "poisoned" them this way. Possibly/probably the lingering toxin is behind my ongoing SFs woes?

When i first created my newest VM, the virgin OpenBox Test VM [Widespread VirtualBox Shared Folders breakage with [Stable Update] 2019-01-17] i was determined to NOT do sudo ./VBoxLinuxAdditions.run. However, by the time of Widespread VirtualBox Shared Folders breakage with [Stable Update] 2019-01-17 i had grown so deflated & defeated that in desperation i did install the ISO's GA in the VM. Thus i assume this VM is now also "ruined", unless i can discover how to fully reverse all changes made by that earlier step. Maybe i need now to create another virgin Test VM & begin all over again?

To all those helping me here: I really do want to solve this, & i really do highly value all the generous help i've received here. However chasing this damn problem has burnt up loads of days & nights recently that ergo has distracted me from important other [unrelated] issues that i really need to do. So for that reason, plus the honest truth that i still feel shattered atm by the intransigence of this problem & my total ineptness to beat it, for the time being i am "parking" this matter. I shall certainly return to it later, & hopefully if my head has cleared maybe i'll see a path forward currently obscured to me.

Forum kindly sponsored by