Description of problem: Host system: 64-bit Mageia 6 Plasma, using 64-bit VirtualBox 5.2.22 as installed from the Mageia 6 repositories, with the 5.2.22 extension pack installed. Guest system: Mageia 7 Plasma system, as installed from the test Round 1 of the Beta 2 LiveDVD iso. The guest system is not auto-mounting shared folders from the host, or if it is I can't find them. The guest user is part of the vboxsf group, and the host user belongs to the vboxusers group. Shared folders do work in other guests, including Mageia 6 and Windows XP. virtualbox-guest-additions was installed by the iso. dkms-vboxadditions was not. I first saw this after an install from the beta 1 iso, but attributed it to /media, where shared folders are typically mounted, not being created. That has been corrected in the beta 2 isos.
Priority: Normal => High
Keywords: (none) => 7beta1
Assigning to tmb.
Assignee: bugsquad => tmbCC: (none) => marja11
I believe this is the same as: Summary: Timing of the nfs mount not working? https://bugs.mageia.org/show_bug.cgi?id=23863 We've seen this before in previous releases.
CC: (none) => wilcal.int
Keywords: 7beta1 => 7beta2
Tested in 7beta3 - still now working properly. I see the following message: Feb 18 12:11:55 localhost VBoxService[699]: 18:11:55.281434 automount vbsvcAutoMountWorker: Shared folder 'vmshared' already is mounted! I go out to /media/vmshared on the VM and it is empty. The hosted folder has quite a few files in it. This isn't resolved.
CC: (none) => brtians1
What's the output of: groups $USER ?
CC: (none) => hamnisdude
(In reply to Kristoffer Grundström from comment #4) > What's the output of: > > groups $USER > > ? In the host, or the guest? Or both?
On VM guest: $ groups $USER brian : brian vboxsf ---- This works fine on the same host and MGA6.
Problem confirmed. M6 x86_64 host, M7 x86_64 guest. Host has Oracle_VM_VirtualBox_Extension_Pack-5.2.24.vbox-extpack installed. In guest, user is member of vboxsf group (logged out/in after adding). $ groups dave vboxsf Comparing the journal on an m6 guest where it's working, to the m7 guest where it isn't, m7 has the following error message ... kernel: vboxsf: Old binary mount data not supported, remove obsolete mount.vboxsf and/or update your VBoxService. As per https://forums.virtualbox.org/viewtopic.php?f=3&t=89187, I also tried following the instruction in the error message with # mv /sbin/mount.vboxsf /root and rebooting. No change. I noticed that on m6 VBoxService is running, but not on m7. On m7 I ran # VBoxService -l VBoxService.log # tail -n 3 VBoxService.log 21:10:03.575104 main vbglR3GuestCtrlDetectPeekGetCancelSupport: Not supported (#3) 21:10:03.587668 automount vbsvcAutoMountWorker: Shared folder 'ROOT' already is mounted! 21:10:03.588564 automount vbsvcAutoMountWorker: Shared folder 'dave' already is mounted! Searching on the not supported message, I think it may be this patch ... https://aur.archlinux.org/cgit/aur.git/tree/012-vbglR3GuestCtrlDetectPeekGetCancelSupport.patch?h=virtualbox-svn Not sure where they got it from as I can't find it on virtualbox.org I did find https://github.com/torvic9/virtualbox/blob/master/012-vbglR3GuestCtrlDetectPeekGetCancelSupport.patch has the same patch
CC: (none) => davidwhodgins
See also https://ml.mageia.org/l/arc/qa-discuss/2019-01/msg00065.html. Removing the obsolete /sbin/mount.vboxsf lets you manually mount a shared filesystem. VBoxService needs to be updated to fix auto-mounting.
CC: (none) => mageia
Problem also exists with a Mageia 7 host, VirtualBox 6.0.4. Even fully updated, as of today, Mageia 7 guests do not automount any shared folders. Shared folders ARE automounted in Mageia 6 guests.
CC: (none) => marci_r
The bug is fixed in the internal QA M7 beta3 isos, and also in an updated installed M7 guest. Works for me.
Still not working here on new installs of Mageia 7 Plasma from the April 11 iso, either in Mageia 7 or Mageia 6 VirtualBox. If an existing Mageia 6 guest is upgraded to Mageia 7, shared folders that had been created in the Mageia 6 guest still work. Tested in Plasma and Xfce 64-bit Mageia 6 guests.
Keywords: (none) => 7beta3
This is a very old bug that hangs around. So far for me all my M7 clients on M6 Hosts are automounting remote shares on the LAN. But, on rare occasions I have to open a su terminal and command: [root@localhost wilcal]# mount -a that works every time.
I am not convinced that your "remote shares" and my "shared folders" are the same thing. The "shared folders" I'm describing have nothing to do with the LAN. This is only a share between host and guest, as described in section 4.3 on https://www.virtualbox.org/manual/ch04.html. The feature is supplied through the guest additions. I tried your suggestion, even though I have never needed it before, once this afternoon and again just now. Each time the command gets this response: mount: /proc: none already mounted or mount point busy. And it didn't help.
TJ: on a fresh vbox guest install, we have to first manually add the user (in the guest) to the vboxsf group, then it works. And of course, the guest-additions package needs te be installed, which is the default. This was always the case, afaik.
CC: (none) => shybluenight
Agreed. And that's the first thing I do on the first boot, even before getting updates. And because I know that the addition to the vboxsf group doesn't take effect until the next login, I always do another boot after getting updates before deciding it isn't working. Even if the user wasn't a part of the vboxsf group, the guest's root ought to be able to see the folders, if they had been auto-mounted. On my systems, he can't. Installing guest additions is the default, yes, but they are being handled differently in Mageia 7 than in past releases. In the past, kernel modules were pre-built and supplied as separate packages. In Mageia 7, I've heard that the modules are included in the kernel. So far, I know of two features supplied by the guest additions that are not working properly for me in Cauldron: This one, and the resolution problem described in Bug 24429. There may be others that I don't use, so I wouldn't know what they are.
Please ignore the part about Bug 24429. It appears that is being caused by the default setting of the Vbox 6.0.4 guest's graphics controller.
Running /usr/sbin/VBoxService mounted the shared folders on my m7 guest.
TJ: I did re-produce the non-working shared folders vy making a fresh M7 guest install, using the latest QA internal beta3 isos. Only after running 'VBoxService' the shared folders became visable. My older installed M7 guests don't have this problem. Something must have changed. So, the bug is not fixed, sorry for the confusion.
Try this (as root): systemctl enable vboxadd-timesync systemctl start vboxadd-timesync (the enable should make it start automatically when you boot) As per comment 18, manual mounting is still broken unless you remove the obsolete /sbin/mount.vboxsf
(In reply to Martin Whitaker from comment #19) > Try this (as root): > > systemctl enable vboxadd-timesync > systemctl start vboxadd-timesync > > (the enable should make it start automatically when you boot) > That takes care of it, Martin. The folders are mounted automatically at boot now. I tried it in two distinct guests. > As per comment 18, manual mounting is still broken unless you remove the > obsolete /sbin/mount.vboxsf I think you mean Comment 8, don't you? OK, so while this isn't fixed yet, at least we know what needs to be done. That's progress.
A quick trial last evening after the vbox update to 6.0.6 resulted in breaking this again on the guests where Martin's commands had been applied. After updating the host, and updating the extension pack, I booted one of the guests that had been "fixed" before. Shared folders were working as expected. But, after updating around 100 packages in the guest, including a new kernel and guest additions, and rebooting, I found them broken again. But it's different this time. There are two mounted editions for each shared folder, one of which has a "_1" at the end of the filename. And when the user tries to bring them up, they come up as empty. The links that I had put in the user's /home to those shared folders are no longer showing, either. During boot and shutdown a message showed on the screen, but it went by too quickly to read anything but "vboxsf." It was too late to investigate further. I suspect that Martin's commands need to be revoked, but at this point I haven't tried to learn how to do that yet.
Having this problem as well, starting vboxadd-timesync solves the issue on VirtualBox 6.0.6 Mageia 6 Cinnamon. I tried Mageia 7 Plasma Beta3 Live as guest. on the other hand, I have some problems with shared folders and Windows 10 guest..! But I do not think that it is related..
I took the guest from Comment 21, stopped and disabled vboxadd-timesync, removed all shared folders, and cleared away the mount points for those folders. This was to get back to a basic situation, the same as a user who hasn't been playing around might see. Both host and guest are Plasma installs, updated to desktop kernel 5.0.8-1 and vbox 6.0.6, including the extension pack in the host and the guest additions in the guest. The host user is part of the vboxusers group, and the guest user is part of the vboxsf group. I then set up two shared folders, one named "Pictures" and the other named "flowers." Each contains digital photos, and each resides in a different directory on the host. Vbox 6.x allows the user to set the mount point but I did not do that, so vbox is supposed to auto-mount them in the guest's /media. After booting the guest, I navigated to /media, and it was empty. After enabling and starting vboxadd-timesync the two folders appeared in /media, but they weren't mounted. (In vbox 6.0.4, the folders would have been auto-mounted at this point.) I tried a reboot of the guest just in case, but there was no change. I've created an attachment of the section of the journal that concerns the automounting errors. This shows two messages for each folder. One is the "obsolete" comment detailed in Comment 7. The other says the folders could not be auto-mounted because it looked like they were already mounted somewhere else. At this point, this is all I've been able to learn. I hope it helps. Raising the priority to release blocker, because this needs to be fixed.
Priority: High => release_blocker
Created attachment 10952 [details] journal of failed automount in vbox 6.0.6
It's failing because tmb has temporarily disabled the patch that fixed it in the previous version: http://svnweb.mageia.org/packages?view=revision&revision=1392059 I guess that means it didn't apply cleanly to the new version, and tmb hasn't had time to fix it. As regards starting the vboxadd-timesync service by default, that's more fallout from the new systemd defaults policy: https://ml.mageia.org/l/arc/dev/2018-10/msg00367.html
(In reply to Martin Whitaker from comment #25) > It's failing because tmb has temporarily disabled the patch that fixed it in > the previous version: > > http://svnweb.mageia.org/packages?view=revision&revision=1392059 > > I guess that means it didn't apply cleanly to the new version, and tmb > hasn't had time to fix it. > OK, I can wait. Not trying to push him to rush. That would be counter-productive. Better to be right than fast. > As regards starting the vboxadd-timesync service by default, that's more > fallout from the new systemd defaults policy: > > https://ml.mageia.org/l/arc/dev/2018-10/msg00367.html OK, I read the thread. Not being a developer in any sense of the word, I don't follow that mailing list. Perhaps I should start. My opinion on this new policy is from the perspective of an outsider. One who knows just enough about Mageia's inner functions to get himself into deep trouble. User/admins like me, who don't really have a clue about what is safe, or where to find out what is safe, or even know that there ARE services that might fix a problem, need some kind of guidance about this, if we are to keep our systems running. This bug should illustrate that. Without your help, I would have had NO idea that there was a service that needed to be activated to get shared folders to work. And I'm not a beginner at this. Beginners, using the Oracle docs as a guide, would have had nothing but frustration even if the patch had worked. I shudder to think where else in Mageia those beginners will wind up being frustrated.
I have virtualbox-6.0.6-2.mga7 building that adds back the disabled patch. It also adds a preset file that allows the service to get actived / started by default
Thank you, tmb. Once I have it, I will test it in an existing M7 guest and I will create a new one with it.
On the existing guest, once I picked up the 225 updates (including the guest additions) the shared folders auto-mounted as they should. The new guest took a little longer. After making a default Plasma install, and getting the updates offered from the installer, I booted, only to find that there were 427 MORE updates to get. (Oh, the joys of Cauldron!) But, once I got them, and rebooted, I checked and the folders had not automounted. Then I remembered to add the user to the vboxsf group. The folders automounted, but the user didn't have access until after a logout/login. In other words, completely expected behavior. Well done, Thomas! Marking this one as resolved.
Status: NEW => RESOLVEDResolution: (none) => FIXED