Why this issue still not assigned?
Anyway
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

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

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

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 && \
reboot

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

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

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

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.