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

The box you're adding has a name different from the name you

Error message

The box you're adding has a name different from the name you
requested. For boxes with metadata, you cannot override the name.
If you're adding a box using `vagrant box add`, don't specify
the `--name` parameter. If the box is being added via a Vagrantfile,
change the `config.vm.box` value to match the name below.

Requested name: %{requested_name}
Actual name: %{actual_name}

What it means

PodmanProvisioner::Installer#ensure_installed (installer.rb:15-21) mirrors the Docker installer: if `@machine.guest.capability?(:podman_installed)` is false it warns — via a hardcoded string rather than an I18n key — "Podman can not be installed" and returns false, skipping detection and installation. The wording is misleading: the actual condition is that Vagrant cannot DETECT whether Podman is installed for this guest OS; it is not a statement that installation is impossible. Everything after (pull/build/run via podman) then depends on Podman already being in the box.

Source

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

            metadata_path = download(
              authenticated_url, env, json: true, ui: false)
            return if @download_interrupted

            File.open(metadata_path) do |f|
              metadata = BoxMetadata.new(f, url: authenticated_url)
            end
          rescue Errors::DownloaderError => e
            raise if !expanded
            raise Errors::BoxAddShortNotFound,
              error: e.extra_data[:message],
              name: display_original_url,
              url: display_url
          ensure
            metadata_path.delete if metadata_path && metadata_path.file?
          end

          if env[:box_name] && metadata.name != env[:box_name]
            raise Errors::BoxAddNameMismatch,
              actual_name: metadata.name,
              requested_name: env[:box_name]
          end

          metadata_version  = metadata.version(
            version || ">= 0",
            provider: provider,
            architecture: architecture,
          )

          if !metadata_version
            if provider
              # If no version found that supports the provider, then the
              # box has no support for the provider
              if !metadata.version(">= 0", provider: provider)
                raise Errors::BoxAddNoMatchingProvider,
                  name: metadata.name,
                  requested: Array(provider).join(", "),

View on GitHub (pinned to 35f3160f4a)

Solutions

  1. Check reality first: `vagrant ssh -c 'command -v podman && podman --version'`.
  2. Preinstall Podman with a shell provisioner (dnf/apt/zypper) before the podman provisioner runs.
  3. Use a base box matching a guest that implements podman_installed (recent Fedora/CentOS/Ubuntu boxes with a current Vagrant).
  4. Upgrade Vagrant so newer podman guest capabilities apply.

Example fix

# Vagrantfile — before
config.vm.provision "podman" do |p|
  p.pull_image "quay.io/libpod/alpine"
end

# after (detection unsupported: install explicitly)
config.vm.provision "shell", inline: "command -v podman >/dev/null || sudo dnf -y install podman"
config.vm.provision "podman" do |p|
  p.pull_image "quay.io/libpod/alpine"
end
Defensive patterns

Strategy: fallback

Validate before calling

# Pre-flight: confirm podman exists in the guest before the podman provisioner runs
vagrant ssh -c 'command -v podman && podman --version'

Type guard

# Where you hold a machine object (plugin/pry context)
def podman_verifiable?(machine)
  machine.guest.capability?(:podman_installed)
end

Prevention

When it happens

Trigger: Using `config.vm.provision "podman"` on a guest whose OS is not handled by a guest plugin registering podman_installed (only a small set of guests implement it), so ensure_installed short-circuits before the podman_install capability is ever invoked.

Common situations: Custom or LTS boxes where the podman capability is missing; podman genuinely not installed, causing the later container steps to fail with 'podman: command not found'; users misled by the message into thinking the install itself is broken rather than the detection.

Related errors


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