Bug#983551: cloud.debian.org: Vagrant/Virtualbox image testing64 ownership of synced_folders is always root

[Henning Sprang <henning.sprang@gmail.com>]

Package: cloud.debian.org
Severity: normal
X-Debbugs-Cc: henning.sprang@gmail.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

I am setting up a system with the debian/testing64 Box provided in the Vagrant Cloud Box Repository, using virtualbox.

The same configuration has been used until yesterday with the debian/buster64 box, and worked as expected.

The Vagrantfile is set up to sync the directory 2 levels above the directory from which vagrant is run and where the Vagrantfile resides
on the host to /work in the guest.

With the buster64 box this works fine.


   * What exactly did you do (or not do) that was effective (or
     ineffective)?

In my working Vagrantfile with buster I changed the value 

config.vm.box = "debian/buster64"

to 

config.vm.box = "debian/testing64" 

And did a vagrant destroy / vagrant up, a "vagrant ssh" to log into the machine, and then an "ls -l /work".

The Vagrantfile has a synced_folder configuration that reads like this:

config.vm.synced_folder "../..", "/work"


   * What was the outcome of this action?


All files and directories in /work on the guest system are the files from the host system, and are owned by root.


   * What outcome did you expect instead?


The expectation is that the synced folder is provided to the guest via nfs and the ownership 
is mapped to the vagrant user in the guest, the default for synced folders as described in the Vagrant documentation.

https://www.vagrantup.com/docs/synced-folders/basic_usage

So that the files in /work are owned by user "vagrant" as they were before when the debian/buster64 box was used.



Additional debugging:

In order to try fixing it, I addionally tried to explicitly set the ownership of the directory changing the line


to

config.vm.synced_folder "../..", "/work", owner: "vagrant", mount_options: ["uid=1000"]

and rebootet / ran "vagrant halt / vagrant up" and also destroyed and rebuilt the machine.
But the result is always the same - those files and directories previously when using the buster64 box being 
owned by "vagrant" keep being owned by "root" now with the testing64 box.
This is making it impossible to do the intened work inside the system as user vagrant.


I did some research trying to see if anyone else has been experiencing this issue, but did not find any clues so far.
So for now I cannot tell if the problem is that the Virtualbox Guest additions are not prepared
for bullseye or if something in bullseye prevents them from working correctly.

Writing that I remember one more possibly releveant thing:

I am using the vbguest vagrant plugin version 0.29.0.
It takes care of the installation of the guest additions, and this also works well with buster64.
I also tried installing the Guest additions provided by the package virtualbox-guest-additions-iso 
burt this results in the system not even starting up proplery with "vagrant up", hanging on 

==> test: Waiting for machine to boot. This may take a few minutes...
    test: SSH address: 127.0.0.1:2200
    test: SSH username: vagrant
    test: SSH auth method: private key

forever, and after canceling the comand with ctrl-c, trying to "vagrant ssh" into it hangs forever, too.

Going to debug further... if you need me to provide any further logs etc, please let me know.

Thank you.