hashicorp
default type for synced folders not working
Per #3631, a global option was requested to provide a default value, of default values, to the type parameter of the config.vm.synced_folder configuration declaration for VM definitions in Vagrantfile.
The issue was closed, with #5013 having been merged and claiming to provide such support. According to the discussion for this merge request, support was added for the global option config.vm.allowed_synced_folder_types.
However, several users reported no benefit from attempting to use this option. I have tested under Vagrant 2.3.1, running under Linux Mint 21, and also found no benefit from assigning a value for this option.
Please clarify the status and design of this feature, as it may be officially supported in current versions, and how to test whether certain observed behavior may represent a bug in the software.
Hey there, please refer to the Vagrant documentation about synced folders for how the type of synced folder is determined.
type (string) - The type of synced folder. If this is not specified, Vagrant will automatically choose the best synced folder option for your environment. Otherwise, you can specify a specific type such as "nfs".
The type option allows you to choose the synced folder plugin that should be used. For example:
config.vm.synced_folder ".", "vagrant", type: smb
The allowed_synced_folder_types restricts the type of synced folders that Vagrant is allowed to use if it needs to determine an appropriate synced folder plugin. For example, a Vagrantfile with the line config.vm.allowed_synced_folder_types = ["nfs"] will only ever try to use the nfs plugin to sync folders.
If you think you have run into a bug please provide a detailed information about it including:
- reproduction steps (including a Vagrantfile)
- what the host system is
- what version of vagrant you are running
- a debug log
If you don't think you have a bug, but you would like to discuss synced folders, I suggest opening up a topic on the Vagrant Discuss Forum.
Please note that the referenced documentation makes no mention of allowed_synced_folder_types. I have created a test, however, which suggest to me that the feature, as just described, is not working properly in my environment.
My system is Linux Mint 21 running Vagrant 2.3.1
Below is a capture of the test.
The option allowed_synced_folder_types is used to constrain folder sharing to use only mounts of type virtiofs. Yet, toward the end of the capture (before the operation was manually terminated), the message is printed, Installing NFS client. When the commented line of Vagrantfile is uncommented, and the test is rerun (from a clean environment), the test will report the mount type of virtiofs rather than NFS.
The debug log is posted externally.
$ lsb_release -a
No LSB modules are available.
Distributor ID: Linuxmint
Description: Linux Mint 21
Release: 21
Codename: vanessa
$ vagrant --version
Vagrant 2.3.1
$ vagrant status
Current machine states:
default not created (libvirt)
The Libvirt domain is not created. Run `vagrant up` to create it.
$ ls -a
. .. .vagrant Vagrantfile
$ cat Vagrantfile
Vagrant.configure("2") do |config|
config.vm.box = "debian/bullseye64"
config.vm.box_url = "ini"
config.vm.provider :libvirt do |libvirt|
libvirt.memorybacking :access, :mode => 'shared'
end
config.vm.allowed_synced_folder_types = ["virtiofs"]
# config.vm.synced_folder ".", "/vagrant", type: "virtiofs"
end
$ vagrant up
Bringing machine 'default' up with 'libvirt' provider...
==> default: Checking if box 'debian/bullseye64' version '11.20220912.1' is up to date...
==> default: Creating image (snapshot of base box volume).
==> default: Creating domain with the following settings...
==> default: -- Name: vagrant_test_default
==> default: -- Description: Source: <basepath>/vagrant_test/Vagrantfile
==> default: -- Domain type: kvm
==> default: -- Cpus: 1
==> default: -- Feature: acpi
==> default: -- Feature: apic
==> default: -- Feature: pae
==> default: -- Clock offset: utc
==> default: -- Memory: 512M
==> default: -- Memory Backing: access: mode='shared'
==> default: -- Management MAC:
==> default: -- Loader:
==> default: -- Nvram:
==> default: -- Base box: debian/bullseye64
==> default: -- Storage pool: default
==> default: -- Image(vda): /var/lib/libvirt/images/vagrant_test_default.img, virtio, 20G
==> default: -- Disk driver opts: cache='default'
==> default: -- Kernel:
==> default: -- Initrd:
==> default: -- Graphics Type: vnc
==> default: -- Graphics Port: -1
==> default: -- Graphics IP: 127.0.0.1
==> default: -- Graphics Password: Not defined
==> default: -- Video Type: cirrus
==> default: -- Video VRAM: 16384
==> default: -- Video 3D accel: false
==> default: -- Sound Type:
==> default: -- Keymap: en-us
==> default: -- TPM Backend: passthrough
==> default: -- TPM Path:
==> default: -- INPUT: type=mouse, bus=ps2
==> default: Creating shared folders metadata...
==> default: Starting domain.
==> default: Waiting for domain to get an IP address...
==> default: Waiting for machine to boot. This may take a few minutes...
default: SSH address: 192.168.121.102:22
default: SSH username: vagrant
default: SSH auth method: private key
default:
default: Vagrant insecure key detected. Vagrant will automatically replace
default: this with a newly generated keypair for better security.
default:
default: Inserting generated public key within guest...
default: Removing insecure key from the guest if it's present...
default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Installing NFS client...
^C==> default: Waiting for cleanup before exiting...
^C==> default: Exiting immediately, without cleanup!
Please note that the referenced documentation makes no mention of allowed_synced_folder_types
True 😬 that has been addressed in this PR https://github.com/hashicorp/vagrant/pull/12938
For the issue with the synced folder, I believe it is coming from the debian/bullseye64 box. In the box's Vagrantfile (located at ~/.vagrant.d/boxes/debian-VAGRANTSLASH-bullseye64/11.20220912.1/libvirt/Vagrantfile) you can see the line config.vm.synced_folder ".", "/vagrant", type: "nfs", nfs_version: "4", nfs_udp: false. This means that, unless specifically overridden in your Vagrantfile, the synced folder type will be nfs. You can read more about how Vagrantfiles are found and merged in the docs. A couple important things to note here:
- the
allowed_synced_folder_typesonly effects determining the default synced folder type. So, it will not override the synced folder type that is specified in the Vagrantfile (as it is in thedebian/bullseye64box). - you can get around this by specifying the type in your Vagrantfile (e.g.
config.vm.synced_folder ".", "/vagrant", type: "virtiofs")
If the box definition includes statements that override the user preference given by allowed_synced_folder_types, then the box design largely defeats the purpose of the option. A principle value of this feature is to allow separation of choosing the mount target versus type.
Would it not be helpful to propagate guidelines to box maintainers for avoiding designs with such problems?
Perhaps the box should set a default, which might be overridden by the user, in the Vagrantfile, for allowed_synced_folder_types.
May we consider the current implementation of the box descriptor to be an open issue that would be considered for a future resolution or is management of the box descriptor beyond the reach of the main project?
Also note, although some of the discussion surrounding the development of the feature represented the possibility of supplying mount options through a map of maps, the documentation changes in #12938 only mention a simple list of mount types.
One important detail about the allowed_synced_folder_types setting is that it is only applicable when Vagrant is guessing at the best synced folder plugin to use for whatever synced folders need that step. So, if the user specifies which synced folder plugin should be used, Vagrant won't try to change that. I think that approach is consistent the rest of Vagrant's approach to config. So, I wouldn't say that this is an open issue.
Would it not be helpful to propagate guidelines to box maintainers for avoiding designs with such problems?
Yep, there are some improvements to be made here around the clarity of what allowed_synced_folder_types means, who should be using that option (consumers of boxes vs. box maintainers), and what the best patterns are box maintenance. I think
- building out a document about best practices around building boxes, and
- increasing the visibility of box level Vagrantfiles can help remedy that.
Also note, although some of the discussion surrounding the development of the feature represented the possibility of supplying mount options through a map of maps, ...
Vagrant does support mount options. From the synced folder docs
mount_options (array) - A list of additional mount options to pass to the mount command.
For example:
config.vm.synced_folder ".", "/vagrant", owner: "vagrant",
group: "vagrant", mount_options: ["uid=1234", "gid=1234"]
...if the user specifies which synced folder plugin should be used, Vagrant won't try to change that. I think that approach is consistent the rest of Vagrant's approach to config. So, I wouldn't say that this is an open issue.
I am not suggesting that calls to synced_folder would not be able to override a value provided by allowed_synced_folder_type, but I am suggesting that from the standpoint of authors of a Vagrantfile, appearances of the former in the box definition should defer to a value given by the latter in the Vagrantfile.
That is, authors of the Vagrantfile should be able to specify a globally uniform, default mount type, which would apply as well to mounts provided by the box definition, without needing to explicitly restate the mount locations from the box definitions in the Vagrantfile. If they are restated, then what is their purpose originally? Is it only to serve those users whose environments and preferences conform to the mount type chosen by the box author?
...the best patterns are box maintenance. I think
building out a document about best practices around building boxes, and
increasing the visibility of box level Vagrantfiles can help remedy that.
Some kind of test or QA process would help, as well as an issue tracker relevant to these concerns. Ideally, the observations in this ticket would be forwarded to the box maintainer, and the issue would be tracked for purposes of revising either the best practices for box maintenance or the conformance to it by the particular box definition.
Also note, although some of the discussion surrounding the development of the feature represented the possibility of supplying mount options through a map of maps, ...
Vagrant does support mount options. From the synced folder docs
The discussion was directed at allowed_synced_folder_types.