hashicorp/vagrant · error · Vagrant::Errors::NoDefaultSyncedFolderImpl

No synced folder implementation is available for your synced

Error message

No synced folder implementation is available for your synced folders!
Please consult the documentation to learn why this may be the case.
You may force a synced folder implementation by specifying a "type:"
option for the synced folders. Available synced folder implementations
are listed below.

%{types}

What it means

For synced folders without an explicit `type:`, Vagrant calls default_synced_folder_type to pick the highest-priority implementation whose usable? passes. If no installed implementation is usable on this host/guest pair, NoDefaultSyncedFolderImpl is raised, listing the implementations Vagrant knows about — meaning the problem is not which type to choose, but that none of them can run.

Source

Thrown at lib/vagrant/action/builtin/mixin_synced_folders.rb:173

            data = data.dup
            if root
              # If these are the root synced folders (attached directly)
              # to the Vagrantfile, then we mark it as such.
              data[:__vagrantfile] = true
            end

            # Keep track of this shared folder by the implementation.
            folders[impl] ||= {}
            folders[impl][id] = data
          end

          # If we have folders with the "default" key, then determine the
          # most appropriate implementation for this.
          if folders.key?("") && !folders[""].empty?
            default_impl = default_synced_folder_type(machine, plugins)
            if !default_impl
              types = plugins.to_hash.keys.map { |t| t.to_s }.sort.join(", ")
              raise Errors::NoDefaultSyncedFolderImpl, types: types
            end

            folders[default_impl] ||= {}
            folders[default_impl].merge!(folders[""])
            folders.delete("")
          end

          # Apply the scoped hash overrides to get the options
          folders.dup.each do |impl_name, fs|
            impl = plugins[impl_name].first.new._initialize(machine, impl_name)
            new_fs = {}
            fs.each do |id, data|
              data[:plugin] = impl
              id         = data[:id] if data[:id]
              new_fs[id] = scoped_hash_override(data, impl_name)
            end

            folders[impl_name] = new_fs

View on GitHub (pinned to 35f3160f4a)

Solutions

  1. Repair the natural default: install/rebuild VirtualBox guest additions (often via `vagrant plugin install vagrant-vbguest` and a `vagrant reload`).
  2. Or make a fallback usable and pin it: install rsync on host and guest, then set `type: "rsync"` on the synced folder.
  3. If you do not need the folder, `config.vm.synced_folder ".", "/vagrant", disabled: true`.
  4. Check the listed implementations against `vagrant plugin list` to confirm which are actually installed.

Example fix

# before
config.vm.synced_folder ".", "/vagrant"   # no type, no impl usable

# after
config.vm.synced_folder ".", "/vagrant", type: "rsync"
# plus once, to repair the VirtualBox default:
#   vagrant plugin install vagrant-vbguest && vagrant reload
Defensive patterns

Strategy: fallback

Validate before calling

# Confirm at least one synced-folder impl can run before relying on the default
command -v rsync >/dev/null && echo "rsync fallback available" || echo "no fallback: install rsync or fix guest additions"
vagrant plugin list | grep -q vagrant-vbguest || echo "consider vagrant-vbguest to keep additions usable"

Prevention

When it happens

Trigger: Folder declarations without `type:` while every registered implementation is unusable: VirtualBox shared folders broken (guest additions mismatch) plus no rsync/nfs available, exotic guests (FreeBSD) with no usable default impl (lib/vagrant/action/builtin/mixin_synced_folders.rb:163-176).

Common situations: Broken/missing VirtualBox guest additions after a kernel update (vboxsf unusable) with rsync also absent; minimal boxes without any shared-folder guest tool; plugin (vagrant-vbguest) failing to rebuild additions; running several providers where the high-priority impl belongs to another provider.

Related errors


AI-assisted analysis of hashicorp/vagrant@35f3160f4a (2026-08-21). Data as JSON: /api/errors/aa38b60408d14c1f. Report an issue: GitHub.