Bug#983551: marked as done (cloud.debian.org: Vagrant/Virtualbox image testing64 ownership of synced_folders is always root)
Your message dated Fri, 19 Mar 2021 10:18:57 +0100
with message-id <firstname.lastname@example.org>
and subject line Re: Bug#983551: 983551: cloud.debian.org: Vagrant/Virtualbox image testing64 ownership of synced_folders is always root
has caused the Debian Bug report #983551,
regarding cloud.debian.org: Vagrant/Virtualbox image testing64 ownership of synced_folders is always root
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact email@example.com
Debian Bug Tracking System
Contact firstname.lastname@example.org with problems
--- Begin Message ---
- To: Debian Bug Tracking System <email@example.com>
- Subject: cloud.debian.org: Vagrant/Virtualbox image testing64 ownership of synced_folders is always root
- From: Henning Sprang <firstname.lastname@example.org>
- Date: Fri, 26 Feb 2021 02:13:39 +0000
- Message-id: <161430561974.115252.9355271944693185010.reportbug@emsv-dev>
*** 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
In my working Vagrantfile with buster I changed the value
config.vm.box = "debian/buster64"
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.
So that the files in /work are owned by user "vagrant" as they were before when the debian/buster64 box was used.
In order to try fixing it, I addionally tried to explicitly set the ownership of the directory changing the line
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.
--- End Message ---
--- Begin Message ---
Disabling vbguest with
config.vbguest.auto_update = false
disables it for the current Vagrantfile without removing the plugin
thanks for the suggestion, I added that to the FAQ
I will now close the bug report and your pull request
(by the way we're now using
https://salsa.debian.org/cloud-team/debian-vagrant-images/ for building)
--- End Message ---