View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004304||Kali Linux||[All Projects] General Bug||public||2017-10-11 09:51||2019-04-02 08:40|
|Target Version||Fixed in Version||2018.4|
|Summary||0004304: virtualbox shared folder|
|Description||After the last update to the virtualbox guest additions v.5.1.28 it is no more accessible the content on the shared folder which always is showed as empty folder.|
|Steps To Reproduce||In a guest kali OS in virtualbox, after the update to the guest additions v.5.1.28 you will verify that the configured shared folder appear always empty.|
|Additional Information||In the machine settings, I tried to delete the configured shared folder and to add a new shared folder again. Restarted the Kali VM, any change in the behavior: the new shared folder appear always empty.|
Why this issue still not assigned?
I tried to manually install manually (because not offered in the automatic update) the three packets (virtualbox-guest-utils, virtualbox-guest-x11, virtualbox-guest-dkms) v.5.1.30 present on the kali repository. And after restarted the problem persist.
After that I installed manually the three packets (virtualbox-guest-utils, virtualbox-guest-x11, virtualbox-guest-dkms) v.5.1.26 present on the kali repository. And after restarted the kali guest work perfectly and the shared folder in correctly mounted in /media/
After upgraded to the 5.1.28 release (the last offered by the automatic update) and restarted, the kali guest again doesn't mount the shared folder in /media/ folder.
Here we are
Do something to correct the bug, please.
Could you resolve the problem releasing a correct version of guest additions for the new virtualbox 5.2.0 release?
||I don't understand what you are requesting. Virtualbox 5.2.0 will come in Kali once it reaches Debian Testing. It just landed in Debian Unstable so you still have a few days to wait. I'm sorry if you have a bug with 5.1.28 but your pet-feature is certainly not critical for Kali. We can't manually handle all the bugs that appear and disappear. That's why we are based on Debian...|
Finally the virtualbox-guest- utils v.5.2.0 arrived in the repository and was installed by the last upgrade, but ... but not resolved the problem originating my post, this post.
The Kali virtual machine continue to not see and access the shared folder.
This problem persist from the v.5.1.26, the last release which worked fine with shared folders.
It is very annoying for a good work the impossibility of access shared folders.
Hope the problem will be solved soon
Today released in the repository and was installed by the last upgrade the virtualbox-guest- utils v.5.2.2 , but ... but not resolved the problem originating my post, this post.
Where is the problem? Why the Kali guest virtual machine can't see the shared folder?
There is somebody else experiencing the same issue?
Thanks to everybody
After examining some logs I've just resolved this issue by doing:
apt update && \
apt install dh-exec && \
apt install --reinstall virtualbox-guest-dkms && \
Hope it helps.
||We have had multiple new version of virtualbox in the mean time. I guess the issues are gone.|
No dear friend the problem is not resolved.
I am now operating under virtualbox 5.2.16 with the last kali virtualbox guest additions updated to the last release 5.2.16 too.
Well, the shared folder is configured as automount but it is not automatically mounted and each time under the guest kali I am obliged to execute the command: mount.vboxsf VMshare /home/[username]/VMshare to access the content of the shared folder.
Ok, it is a minor bug. But it is a bug anyway. Constantly present from the release 5.1.28 of the virtualbox guest additions, until now.
Here we are.
Good job and Best Regards.
||Ok, the no-automount bug is not important enough for us to invest resources into it. If it does still exist, you should try to report it to Debian or to upstream to get it fixed. We are not virtualbox developers.|
"Ok, the no-automount bug is not important enough for us to invest resources into it."
I can agree with this, but you must know:
1) actually with Kali rolling until today upgraded under virtualbox 5.2.22 the problem still persist.
2) It is not a virtualbox problem but a kali guest problem under virtualbox still present from the v.5.1.26, virtualbox/kali guest additions release. This problem is not present in a guest PureOS under Windows7 host and it is not present in a guest Windows10 under Kubuntu host; both of them under virtualbox 5.2.22 and with standard virtualbox guest additions. The problem likely reside in the Kali version of guest additions.
All this for your knowledge.
||Thanks for the updates.|
Ah, that's intesting information. Does it mount the shared folder when you do "systemctl start virtualbox-guest-utils"?
Is the problem permanently fixed when you do "systemctl enable virtualbox-guest-utils"?
||If my guess was correct, then this will be fixed for new images with base-files 2019.1.0 and above (I whitelisted virtualbox-guest-utils.service as a safe service to start by default).|
I tried the solution you indicated, but it not fixed the problem:
1) after run "systemctl start virtualbox-guest-utils" the content of the shared folder remain not accessible.
2) after run "systemctl enable virtualbox-guest-utils" and after restarted the content of the shared folder always not accessible in spite of the service result started and active.
3) then always I need to run the appropriate command ("mount.vboxsf [destination folder] [source folder]"). After that the content of the shared folder become accessible.
Apparently your "guess" wasn't correct.
||Do you still have this problem with Kali 2019.1? If yes, can you paste the output of "systemctl status virtualbox-guest-utils"? Thank you.|
Well, this is the situation:
1)- Originally I installed in virtualbox the "kali-linux-kde-2017-1-amd64.iso" and constantly upgraded. Actually it runs under virtualbox 6.04 with the appropriate guest additions.
2)- The output of systemctl status virtualbox-guest-utils, is:
● virtualbox-guest-utils.service - Virtualbox guest utils
Loaded: loaded (/lib/systemd/system/virtualbox-guest-utils.service; disabled; vendor preset: enabled)
Active: inactive (dead)
3)- I imported in virtualbox the appliance "kali-linux-2019.1-vbox-amd64.ova" and I saw that it worked well starting and auto-mounting the shared folder. I saw also that the virtualbox-guest-utils service was started.
4)- Then in my original installation I run "systemctl start virtualbox-guest-utils" and after that the shared folder was normally accessible.
5)- After that I run "systemctl enable virtualbox-guest-utils" and I reboot the kali VM.
6)- The system started normally, but at login after inserted the user password, a small window open telling me:
"Could not start kdeinit5. Check your installation." I press on the Okay button but the system doesn't start and remain on a black screen.
I remember you that this problem persist from the v.5.1.26, the last release which worked fine with shared folders.
Here we are.
Thanks for your attention
So the problem is fixed. I don't see how the kdeinit failure could be related. If anything, this should be a separate bug report. But if you don't reproduce it on a fresh install, then it's not really worth investigating much longer.
Thank you for your patience. Closing this ticket now.
|2017-10-11 09:51||erasmo52||New Issue|
|2017-10-24 11:55||erasmo52||Note Added: 0007555|
|2017-10-26 07:19||erasmo52||Note Added: 0007564|
|2017-10-26 08:03||rhertzog||Note Added: 0007565|
|2017-10-26 08:03||rhertzog||Assigned To||=> rhertzog|
|2017-10-26 08:03||rhertzog||Status||new => assigned|
|2017-11-13 08:22||erasmo52||Note Added: 0007594|
|2017-12-01 11:57||erasmo52||Note Added: 0007651|
|2018-01-29 17:11||mike386||Note Added: 0008538|
|2018-06-22 06:19||g0tmi1k||Severity||major => minor|
|2018-07-27 10:31||rhertzog||Status||assigned => resolved|
|2018-07-27 10:31||rhertzog||Resolution||open => fixed|
|2018-07-27 10:31||rhertzog||Note Added: 0009395|
|2018-07-28 15:39||erasmo52||Status||resolved => feedback|
|2018-07-28 15:39||erasmo52||Resolution||fixed => reopened|
|2018-07-28 15:39||erasmo52||Note Added: 0009402|
|2018-11-23 10:43||rhertzog||Status||feedback => closed|
|2018-11-23 10:43||rhertzog||Fixed in Version||=> 2018.4|
|2018-11-23 10:43||rhertzog||Note Added: 0009973|
|2018-11-24 07:46||erasmo52||Status||closed => feedback|
|2018-11-24 07:46||erasmo52||Note Added: 0009987|
|2018-11-24 11:13||muts||Status||feedback => closed|
|2018-11-24 11:13||muts||Note Added: 0009988|
|2018-11-25 10:55||rhertzog||Status||closed => assigned|
|2018-11-25 10:55||rhertzog||Note Added: 0009989|
|2018-11-25 11:04||rhertzog||Note Added: 0009990|
|2018-11-26 07:42||erasmo52||Note Added: 0009996|
|2019-03-29 16:44||rhertzog||Status||assigned => feedback|
|2019-03-29 16:44||rhertzog||Note Added: 0010464|
|2019-04-02 07:49||erasmo52||Note Added: 0010471|
|2019-04-02 07:49||erasmo52||Status||feedback => assigned|
|2019-04-02 08:40||rhertzog||Status||assigned => resolved|
|2019-04-02 08:40||rhertzog||Resolution||reopened => fixed|
|2019-04-02 08:40||rhertzog||Note Added: 0010472|