By the way, my shared folders appear to be working fine after the last update.
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).
Well, I only run Windows guests, so maybe that’s part of the problem.
Yes, I’M not sure if it comes from
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.
It would be useful as a control in your testing. No need to configure it for everyday usage, just leave it as is with shared folders configured (you’ll still need to manually mount though). Over time see if these break in the same way your other VM SFs break.
I have never run the voboxadditions ISO script in any Manjaro VMs and my shared folders have always worked,
virtualbox-guest-utils is the only other package installed.
Just an update on this.
After some slight testing, for VirtualBox 6.0.2 on kernel 4.20.7 with Windows 7 guest on a Linux host, shared folders seems to work.
I’m happy for you, but not surprised, given that SF continued to work just fine for ALL my non-Manjaro Guests, running in my Manjaro Host. For me, those non-Manjaro’s were never a problem… instead the problem has always only been my Manjaro Guests. I’ve still not got their SFs working [but i have not worked on this problem at all since my previous posts].
…and indeed, that’s what i HAVE now done this afternoon. Consequently, once more i now have:
vboxadd.service[began with VB v6, afair]
# except my Xfce VM, which per its long-term history, remains a bizarre basket-case of silliness.
EDIT: Have now done the same thing to my Unstable & Testing VMs, which as consequence also once more have working SFs.
Irony: Doing the “right” thing broke my SFs. Doing the “wrong” thing fixed them again.
Am marking this Solved, to put this laboured thread out of its misery.
I spoke too soon, further testing (e.g. trying to do some actual work) gives that for me the issue is still there, even on my Windows guests. It is interesting that those works for you, I wonder then what might be the difference? I still think that this is a specific bug introduced in Virtualbox 6 and our problems stems from a common underlying problem, irrespective of the guest OS.
I don’t understand your solution, but I guess it is Manjaro guest-specific?
Oh? Bad luck. I no longer have a Win7 VM, but i do have an XP & Win8 VM [one of each, i mean], & 2x Win10 VMs. Typically i only fire any of them up on days when i’ve become bored with poking out my eye with a burnt stick, but given your new post, i’ll grab my stick & launch them now to double-check my previous observation that their SFs were still good. Back in a tick or three…
Update: I didn’t have the stomach to bother with the Win8 VM, but in the other three, the VMs’ SFs continue to work just fine [well, with one caveat].
Caveat: one of the two Win10 VMs has a long-term idiosyncrasy re its VMs. Pretty much each time i run it, it seems to change its alphabetical identifier prefix for that “drive”, such that my desktop shortcuts break. Upon inspecting My Computer, i usually [maybe always] see the stupidity of these “drives” (ie, SFs) being duplicated & in one case triplicated. That Redmond-idiocy aside, these links themselves within My Computer, DO all work… they do jump me into my associated Host directory.
Ouch, I feel for your eyes. I would not do it myself unless it were necessary for work.
I should define “not working” a bit more clearly. The shared folders automatically mount and show up fine. I can open files, sometimes (often in the beginning) I can also save files, but writing is problematic and becomes unstable after “a while”, at that point then the whole WM becomes unstable and brokenness escalates until it no longer responds to user input. I have only seen this happening on VirtualBox 6 (5 has always been stable).
I did some digging and found this thread (Virtualbox windows 10 guest no shared folder) suggesting adding the user to the vboxsf group is needed for file sharing, my user was not in this group (indeed the group did not even exist), I assume this group is no longer needed, but I added it anyway and added my user.
Right now it looks like it works, but I don’t trust it until it has proven to be stable over time. I’ll report back when I’ve tested it more to see if this group actually makes a difference.
Oh golly, if you had not been doing this before i am amazed that you got any functionality out of it at all. Afaik that’s a very long-term requisite.
Also, i don’t understand your earlier
I don’t understand your solution. It is nothing more than the standard way to create & operate VB VMs’ Guest Additions functionality. You load the GA ISO into the virtual optical drive via
…after which Win will / should detect the disk & offer you the usual Windoze choice to run / open / poke out your eye with burnt stick. You run it, let it do its stuff, then you need to reboot the VM. Have you not been doing this stuff?
In my ignorant state I just let the packages deal with the groups (and I can report that the vboxsf group was not necessary for stable shared folders between my Manjaro host and my Win 7 guest on VirtualBox 5). My user was however, in the other groups (virtualbox, vboxusers, uucp).
So if I understand, your solution was doing it the (not recommended) “windows way” on your Manjaro guest and it worked, is that correct? I guess it is not applicable to my situation since mounting the ISO and running it is the only way on windows…
Yes, of course, I’ve been running VirtualBox for years . Only thing I did not have was that group which were either not needed before (or it the group was erroneously removed by a to me unknown process, I mean that is always a possibility since I do not check the groups very often…).
Thanks for reporting on your win guests. I’ll check back in with the results when I’ve done some more in depth testing (more work coming up!). If I cannot get to be stable on 6 I will need to find a way to build 5.2.26 since it has support for Linux 5.0 (which I suppose means it will also support 4.20). Hopefully it will not require too much effort taking the latest Manjaro PKGBUILD of the 5 series and adjusting it to point to the 5.2.26 files. But first I hope was just the lack of the group that made it unstable!
Yeah, that’s it. Btw it’s not just the “windows way”, coz that’s the way to do it for pretty much any VM including non-Manjaro Linux Guests. My extreme naughtiness was to [as you noticed] also apply this method to all my Manjaro VMs. Prior to VB v6.x, despite being contrary to “the Manjaro way”. this simply “worked” for me, thus was entirely unremarkable. From v6, things went downhill [only wrt my Manjaro Guests, i mean; all my others stayed happy]. I began having those loooong Stop / Start jobs during SD / SU of the Manjaro Guests, & when i decided to try to combat those, by strictly applying “the Manjaro way”. i succeeded in eliminating the delays, for the entirely minor inconsequential price paid of… breaking all my SFs [all SFs showed as being empty]. I am not & shall not advise any other Manjaroo to follow my lead… but if they ever experience their own version of VB SF purgatory, they might become desperate enough to also try my dark path.
Set the shortcuts to
\\vboxserver\ instead of using the drive letter.