hashicorp/vagrant · warning · Vagrant::Errors::BoxAddNoMatchingArchitecture

The box you're attempting to add doesn't support the request

Error message

The box you're attempting to add doesn't support the requested
architecture with the current provider. The following providers
support the requested architecture for this box:

  %{supported_providers}

If the above providers cannot be used, please find and alternate
box that supports the requested architecture.

Box: %{name}
Address: %{url}
Architecture: %{architecture}
Provider: %{provider}

What it means

In rsync-auto (rsync_auto.rb:69-74), the watcher compares the synced folders cached at last boot (`synced_folders(machine, cached: true)`) against a fresh read of the current Vagrantfile. When the fresh config contains folders the cached set does not (diff[:added] non-empty), it warns "New synced folders were added to the Vagrantfile since running `vagrant reload`. If these new synced folders are backed by rsync, they won't be automatically synced until a `vagrant reload` is run." The watcher then iterates only the cached folders, so additions are ignored for the lifetime of the process.

Source

Thrown at lib/vagrant/action/builtin/box_add.rb:301

              # If no versions are found, then the box does not provide
              # support for the requested architecture using the requested
              # architecture
              if available_versions.empty?
                supported_providers = metadata.versions(architecture: architecture).map do |v|
                  metadata.version(v).providers(architecture)
                end.compact.uniq.sort

                # If no providers are found, then the box does not
                # have any support for the requested architecture
                if supported_providers.empty?
                  raise Errors::BoxAddNoArchitectureSupport,
                    architecture: display_architecture,
                    name: metadata.name,
                    url: display_url
                end

                raise Errors::BoxAddNoMatchingArchitecture,
                  provider: Array(provider).join(", "),
                  architecture: display_architecture,
                  name: metadata.name,
                  url: display_url,
                  supported_providers: supported_providers
              end

              raise Errors::BoxAddNoMatchingProviderVersion,
                constraints: version || ">= 0",
                provider: Array(provider).join(", "),
                architecture: display_architecture,
                name: metadata.name,
                url: display_url,
                versions: available_versions.reverse.join(", ")
            else
              # Report that no version can match the constraints requested
              # but show what versions are supported
              raise Errors::BoxAddNoMatchingVersion,

View on GitHub (pinned to 35f3160f4a)

Solutions

  1. Stop rsync-auto (Ctrl-C), run `vagrant reload` to re-baseline the cached synced folders, then restart `vagrant rsync-auto`.
  2. If a reload is not convenient right now, push once manually with `vagrant rsync <machine>` and schedule the reload.
  3. Confirm the baseline afterwards: restart rsync-auto and check the warning no longer appears and 'Watching: <path>' lists the new host path.

Example fix

# before (warning: new synced folders were added...)
#   Vagrantfile edited to add a folder, then:
vagrant rsync-auto

# after
vagrant reload && vagrant rsync-auto
Defensive patterns

Strategy: validation

Validate before calling

# After any Vagrantfile folder edit, re-baseline before watching:
vagrant reload && vagrant rsync-auto

Prevention

When it happens

Trigger: Editing the Vagrantfile to add an rsync synced folder (or starting rsync-auto against a machine whose data-dir cache predates recent Vagrantfile edits), then running `vagrant rsync-auto` — the cached-vs-fresh diff shows the addition and the warning prints once per machine per start.

Common situations: Developer adds a folder while rsync-auto is already running (or after `vagrant up` but before any reload) and wonders why edits never reach the guest; multi-machine Vagrantfiles where one machine got new folders; stale .vagrant cache after aborted reloads.

Related errors


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