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

virtualbox

#1

I’ve created this separate thread so as to not clutter the Update thread. My parent post is [Stable Update] 2019-01-17 - Kernels, KDE Apps, KDE Plasma, Deepin, Firefox, Calamares, XFCE

All but one of my Stable VMs’ Shared Folders broke again today when i did this update in them [but the Unstable & Testing VMs’ SFs remained good; the one Stable VM that did not break was OpenBox, so it must have some powerful magic built into it]. I’m just about to now do the update to my Stable Host [in which those VMs run], & i hope that somehow automagically makes the SFs work again. Getting my VM SFs to work, then stay working, has been an ongoing roller-coaster for sooooooooooo long.

Post-Update Update: Testing & Unstable VMs’ SF’s remain good. Stable Xfce, KDE, Enlightenment & Cinnamon VMs’ SFs remain broken. Stable OpenBox VM’s SFs remained good at first, but later also broke. Sigh. Testing VM’s SFs were perfectly good initially after the Host’s update, but later decided also to break.

A common factor for most* of those bad VMs is that VB’s Session Information tool persists in the delusion that the wrong GA version remains installed:

20190118_001
*not the OpenBox Stable VM, nor the KDE Testing VM, both of which still indicate the right version.

In those recalcitrant VMs i’m now considering reinstalling the VB ISO’s GA [sudo ./VBoxLinuxAdditions.run ], accepting i’ll once again have to have the multi-minutes VM SU & SD, but at least [maybe] getting my SFs back. Running VMs without SFs reduces the efficacy of those VMs for me by half.

Post-Update Update Update: Oh Zeus, now also OpenBox Stable VM SFs have broken , but in a specially exciting new way, different to all the others [nice, i was getting bored]. Once i discovered that now its SFs have also become broken just like every other Stable VM today, i checked in its Pamac to see what version of virtualbox-guest-utils is actually installed, only to see that it is not installed at all [but it definitely was installed prior to today’s Stable Update]. So i tried to install it, only to get:

conflicting files:
virtualbox-guest-utils: /etc/xdg/autostart/vboxclient.desktop already exists in filesystem
virtualbox-guest-utils: /usr/bin/VBoxClient already exists in filesystem
virtualbox-guest-utils: /usr/bin/VBoxClient-all already exists in filesystem
virtualbox-guest-utils: /usr/bin/VBoxControl already exists in filesystem
virtualbox-guest-utils: /usr/bin/VBoxService already exists in filesystem
virtualbox-guest-utils: /usr/bin/mount.vboxsf already exists in filesystem
virtualbox-guest-utils: /usr/lib/VBoxOGL.so already exists in filesystem
virtualbox-guest-utils: /usr/lib/VBoxOGLarrayspu.so already exists in filesystem
virtualbox-guest-utils: /usr/lib/VBoxOGLcrutil.so already exists in filesystem
virtualbox-guest-utils: /usr/lib/VBoxOGLerrorspu.so already exists in filesystem
virtualbox-guest-utils: /usr/lib/VBoxOGLfeedbackspu.so already exists in filesystem
virtualbox-guest-utils: /usr/lib/VBoxOGLpackspu.so already exists in filesystem
virtualbox-guest-utils: /usr/lib/VBoxOGLpassthroughspu.so already exists in filesystem

What is going on here? Is it safe to manually delete all those files, then reattempt to install virtualbox-guest-utils?

There’s so much wrong here now [ironically the ONLY good one is my Unstable VM] that maybe the better tactic might be to return to VB v5.2.x?

Final clarifications:

  1. as of yesterday, SFs in ALL my VMs worked fine [except my Xfce VM, which has been a basket case for ages]. Today’s Stable Update has really ruined the VB VM SF party here.
  2. In all respects other than the SFs, all my VMs seem perfectly fine & happy.

Manjaro guest additions
Virtualbox not automounting shared folder in guest (Manjaro KDE v18.0.2)
#2

Did you check to see if pacman identifies a package as owning those files with pacman -Qo?


#3

Thanks. Do you mean like

[kdemeoz@manjaro-openbox-VM ~]$ pacman -Qo virtualbox-guest-utils
error: No package owns virtualbox-guest-utils

or do you mean, eg,
pacman -Qo /etc/xdg/autostart/vboxclient.desktop
& so on?


#4

Like this. The individual files. It should tell you which package those files belong to.

You don’t need to check them all though. Just one or two.


#5

My question was really silly, wasn’t it… even by my standards! I tried one, with same bad result:

[kdemeoz@manjaro-openbox-VM ~]$ pacman -Qo /etc/xdg/autostart/vboxclient.desktop
error: No package owns /etc/xdg/autostart/vboxclient.desktop

Something really got screwed up here… & then there’s all my other VMs too with their different failure mode for SFs. Such a mess.


#6

That is why i never install the Virtual Guest from ISO, but always and only the packages from the repositories.

$ pacman -Qo /etc/xdg/autostart/vboxclient.desktop
/etc/xdg/autostart/vboxclient.desktop is owned by virtualbox-guest-utils 6.0.0-3

Indeed i can’t automount the share folders at boot, but i make use of this from the guest install:
sudo mount -t vboxsf Share_Name /run/mount


#7

Thanks Bogdan. Tomorrow i am going to re-read the Wiki, test your recommendation too, & try to persuade myself that i am no longer “allowed” to create & automount Shared Folders the way i had done for years [pre-Manjaro]. I shall really miss this convenience:


[Testing Update] 2019-01-19 - Kernels, Mesa, Browsers, Nvidia, Deepin, VirtualBox
#8

I think it can be automated tho. I’ll look into it once i have a bit more clear mind …


#9

I’ve also been experiencing some breakages on my Windows’ guests. The workaround I’ve been applying is to change the drive/mountpoint of the shared folders using the VBox manager. Then, as I have shortcuts to a lot of folders on my guests, I change it again to my usual drive/mountpoint. From that point it works until the next reboot/resume. It is an annoyance :unamused:


#10

Yes, this! What i was seeing was at time-0 my SFs were good. At time-1 i Closed said VMs. At time-2 i Resumed the VMs, & as that was underway i could see my SFs still being ok in Dolphin [of the VM], but then once the Resume was fully finished, pouff, zap, the SFs vanished right in front of me. I thought i was going mad. Anyway, zzzz-time now.


#11

Now i perfectly understand the frustration. Tried this and used some stuff from one of your previous posts (that are always well organized, well written and documented each step) … You know what? I gave up after 2 hours, i couldn’t get it working. :frowning:

Maybe because i never had to write from guest to those shared folders and i don’t access them all the time, i became lazy and used the simplest way for mount.


#12

Yup completely broken. I can’t even get it to work by downgrading to a version that I know worked before (5.2.22). This sucks ass, I’m completely unable to work on a project for work. FML.

This should be absolute top priority to be fixed in the next update. Not even sure how it made it to [Stable] like this. QC fail :frowning:


#13

I’m grateful that some others have confirmed they also have similar problems.

For me the absence of SFs is not exactly crippling, as i suppose i can revert to transferring files/docs i need via USB stick, but it’s certainly a royal pain. Alternatively I might need to return to some of my non-Manjaro VMs , whose SFs still work, until whatever the hassle is with my Manjaro VMs’ SFs goes away.


Edit: I’ve just tested my KaOS VM, but it took a while coz [not having used it for several weeks] it needed a huge update. After that had finished, & before i rebooted it, i feared the worst, having seen this in its Octopi terminal:

(267/270) upgrading virtualbox-ext-oracle                             [--------------------------------------] 100%
error: command failed to execute correctly

Pleasingly though, post-reboot [of the VM only; duh] both my SFs in it are good.


#14

Ouch. scp/sftp isn’t an option?


#15

Golly - looks like today i need to do some more research to learn what this is. Thanks. Mind you, deluded fool that i am, i kinda sorta just wish that my Manjaro VM SFs “just worked”, like they used to do, once upon a time.


#16

Well i’m just exasperated sufficient to blow a foofle-valve. Have wasted several more hours today, for NO benefit.

  1. Chose my existing Xfce & OpenBox Stable VMs [in my Stable KDE Tower], as today’s investigative guinea pigs. ALL my VMs’ SFs are broken now [for a few days], but i wanted to just focus on a subset today.
  2. Compared both https://wiki.manjaro.org/index.php?title=Virtualbox & [Wiki][VirtualBox] Installation, USB devices and Shared folders to my vbox setup & settings in said VMs. Could not find any obvious discrepancies.
  3. Pondered if maybe some residual vbox systemd unit file from some long-forgotten historical idiocy i’d perpetrated, might now be causing the recent misery, so to eliminate that possibility i…
  4. …created a brand spanking new VM today, using Manjaro OpenBox ISO, & scrupulously followed those wikis.
  5. Verified that VM’s:
~ >>> pacman -Qo /etc/xdg/autostart/vboxclient.desktop                          
/etc/xdg/autostart/vboxclient.desktop is owned by virtualbox-guest-utils 6.0.0-3
  1. Observed that that VM’s /usr/lib/systemd/system/vboxservice.service is:
[Unit]
Description=VirtualBox Guest Service
ConditionVirtualization=oracle

[Service]
ExecStartPre=-/usr/bin/modprobe vboxguest
ExecStartPre=-/usr/bin/modprobe vboxvideo
ExecStartPre=-/usr/bin/modprobe vboxsf
ExecStart=/usr/bin/VBoxService -f

[Install]
WantedBy=multi-user.target

Dunno if that’s good or bad, but it is what it is.

  1. The dogdamn brand spanking new SFs are broken… just as broken as all my other Manjaro VMs [ie, they relentlessly display nil contents].

  2. Finally, further indication that something here is clearly Crook in Muswellbrook / Crook as Rookwood [>Straya, = Sh1t!], is that despite all the preceding careful steps, the bleedin’ new VM refuses to fill my monitor; it retains its small square window-pane within my otherwise maximised VM window in my Host… ie, visually it looks no different to before i did my sudo pacman -Syu virtualbox-guest-utils & VM-reboot. Sigh.

Tomorrow, if i can summon any enthusiasm given this feels like flogging a dead horse, i might try these…

  1. Virtualbox not automounting shared folder in guest (Manjaro KDE v18.0.2)
  2. Widespread VirtualBox Shared Folders breakage with [Stable Update] 2019-01-17
  3. Virtualbox not automounting shared folder in guest (Manjaro KDE v18.0.2)

…but i have never needed to do any of those before to get my SFs working, so i feel very sceptical now.

Basically unless i am continuing to overlook some critical missed step, or have repeated some stupid causation error, it simply smells to me like there’s something seriously broken with our current Manjaro VirtualBox.


EDIT: For full disclosure, i should mention this. Where [Wiki][VirtualBox] Installation, USB devices and Shared folders says to do:

Mounting the shared folders
On guest system you need to create the mount folder manually

sudo mkdir /media

, i skipped this step, as 100% of the times that i’ve created new VMs i find that automagically, without needing manual intervention from me, /media always already exists in the Guest. I thus long ago assumed this step is redundant. Am i mistaken? Is this my big error & the cause of my SF misery?


#17

Well, it’s OT for the Shared Folders problem, but it’s nice still to get even a small win. This weirdness is solved, but the root cause was… weird. Whilst i have dozens of VMs, this special test OpenBox one is my first one created since VirtualBox updated to v6. All of my older Linux VMs use Display Graphics Controller VBoxVGA, which was the default parameter at the time… i never touched this setting, just accepted it, & it always worked fine for me.

During today’s investigation i was surprised to discover that for this new VM, a different parameter was set… VMSVGA. Huh, why different? After shutting down the VM & changing back this to the other parameter, voila, my new Test VM now correctly maximises to fill the maximised window on my monitor. Very strange.

Now, back to fighting the Shared Folders. It galls me that SFs still work fine in my KaOS & ArchLabs VMs… but so far no longer in my Manjaro VMs [despite of course in olden times working fine].


#18

Results:

  1. Did not work [my SFs continue to wrongly appear “empty”]
  2. Did not work [/usr/bin/mount.vboxsf: mounting failed with the error: Protocol error]
  3. Did not work [/usr/bin/mount.vboxsf: mounting failed with the error: Protocol error]

I am unfamiliar with all those procedures, so i cannot rule out that i might have misunderstood what to do & hence misapplied the procedure… but i did try hard to do it right.

The only thing that did work today, in this Test VM, is that procedure that we are told [per the two Wikis i’ve earlier mentioned] we should NOT do in our Manjaro Guests: sudo ./VBoxLinuxAdditions.run & reboot. It thereafter entails that new ~2’ delay during VM SU & SD to start & stop this service… but if it gives me my SFs then i suppose i must accept this price.

PS: Given the details in my OP, + my Widespread VirtualBox Shared Folders breakage with [Stable Update] 2019-01-17, i do not really have great confidence that these SFs will remain good hereafter, across future VM Suspends, Resumes, & Reboots.


#19

That’s the VMWare graphics adapter. It works very well here with Manjaro guests (+ guest modules which are compulsory), seems to be faster than the legacy VBoxVGA.

EDIT:
MacOS host + Manjaro guest = Shared folders work as intended.
(mount -t vboxsf name_of_share /mountpoint)

Is your guest user part of the vboxsf group?


#20

Aha [re the adaptor]! Ta.

Yes.

kdemeoz@manjaro-ob-vm Linux 4.19.14-1-MANJARO x86_64 18.0.2 Illyria
~ >>> id                                                                        
uid=1000(kdemeoz) gid=1000(kdemeoz) groups=1000(kdemeoz),3(sys),90(network),98(power),109(vboxsf),991(lp),998(wheel)
~ >>>

Please can i now double-check my understanding of this? Am i interpreting the intention correctly if i rewrite that string as:
mount -t vboxsf FULL_path_to_name_of_share /FULL_path_to_mountpoint ?

If that’s incorrect, then that’s possibly why my earlier attempts failed.