View Issue Details

IDProjectCategoryView StatusLast Update
0004304Kali Linux[All Projects] General Bugpublic2019-04-02 08:40
Reportererasmo52 Assigned Torhertzog  
Status resolvedResolutionfixed 
Product Version2017.2 
Target VersionFixed in Version2018.4 
Summary0004304: virtualbox shared folder
DescriptionAfter 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 ReproduceIn 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 InformationIn 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.



2017-10-24 11:55

reporter   ~0007555

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


2017-10-26 07:19

reporter   ~0007564

Could you resolve the problem releasing a correct version of guest additions for the new virtualbox 5.2.0 release?
Thank you


2017-10-26 08:03

administrator   ~0007565

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


2017-11-13 08:22

reporter   ~0007594

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
Thank you


2017-12-01 11:57

reporter   ~0007651

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


2018-01-29 17:11

reporter   ~0008538

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.


2018-07-27 10:31

administrator   ~0009395

We have had multiple new version of virtualbox in the mean time. I guess the issues are gone.


2018-07-28 15:39

reporter   ~0009402

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.


2018-11-23 10:43

administrator   ~0009973

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.


2018-11-24 07:46

reporter   ~0009987

"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.
Best Regards


2018-11-24 11:13

reporter   ~0009988

Thanks for the updates.


2018-11-25 10:55

administrator   ~0009989

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"?


2018-11-25 11:04

administrator   ~0009990

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


2018-11-26 07:42

reporter   ~0009996

Dear friend,
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.


2019-03-29 16:44

administrator   ~0010464

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.


2019-04-02 07:49

reporter   ~0010471

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


2019-04-02 08:40

administrator   ~0010472

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.

Issue History

Date Modified Username Field Change
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