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

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.

1 Like

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:

2 Likes

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.

Ouch. scp/sftp isn't an option?

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.

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

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].

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.

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?

1 Like

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.

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

20190122_001

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:

20190122_002

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:

2 Likes

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.

1 Like

Forum kindly sponsored by