On 2/26/21 3:13 AM, Henning Sprang wrote:
Package: cloud.debian.org
Severity: normal
X-Debbugs-Cc: henning.spr...@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.
Hi Henning
Thank you for your interest for the Debian boxes and the detailed bug
report.
Actually, you don't need anymore the vagrant-vbguest pluging for testing
boxes, as all drivers are now in the main debian kernel. Can you try to
destroy the box, and recreate the boxes without the vagrant-vbguest
plugin to see if that helps ?
Also are you sure you're using NFS inside the box, did you configure
that manually, as the default filesharing mechanism for VirtualBox
vagrant boxes is vboxsf.
You can check with
grep work /proc/mounts
what is the shared folder mechanism you're using.
Last question, what is your host system ?
This might plays a role if you're using NFS, as maybe NFS server and
client mount options don't play well.
