[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 <9a728a1d-0a8d-55f3-bc42-836cfbb49694@libera.cc>
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 owner@bugs.debian.org

983551: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983551
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
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

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.

Additional debugging:

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

--- 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 https://wiki.debian.org/Teams/Cloud/VagrantBaseBoxes#Unable_to_use_the_vagrant-vbguest_plugin

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

Reply to: