hashicorp/vagrant · error · Vagrant::Errors.VirtualBoxUserMismatch

The VirtualBox VM was created with a user that doesn't match

Error message

The VirtualBox VM was created with a user that doesn't match the
current user running Vagrant. VirtualBox requires that the same user
be used to manage the VM that was created. Please re-run Vagrant with
that user. This is not a Vagrant issue.

The UID used to create the VM was: %{original_uid}
Your UID is: %{uid}

What it means

Before querying VM state, the VirtualBox provider verifies that the UID stored in the machine's data dir (`@machine.uid`, recorded when the VM was created) matches the current Process.uid. VirtualBox user-level state cannot be managed across users, so a mismatch raises VirtualBoxUserMismatch with both UIDs. There is an explicit bypass for WSL Windows access when the user opted into it via wsl_windows_access_bypass? for the data dir.

Source

Thrown at plugins/providers/virtualbox/provider.rb:97

        return {
          host: "127.0.0.1",
          port: @driver.ssh_port(@machine.config.ssh.guest_port)
        }
      end

      # Return the state of VirtualBox virtual machine by actually
      # querying VBoxManage.
      #
      # @return [Symbol]
      def state
        # We have to check if the UID matches to avoid issues with
        # VirtualBox.
        if Vagrant::Util::Platform.wsl_windows_access_bypass?(@machine.data_dir)
          @logger.warn("Skipping UID check on machine by user request for WSL Windows access.")
        else
          uid = @machine.uid
          if uid && uid.to_s != Process.uid.to_s
            raise Vagrant::Errors::VirtualBoxUserMismatch,
              original_uid: uid.to_s,
              uid: Process.uid.to_s
          end
        end

        # Determine the ID of the state here.
        state_id = nil
        state_id = :not_created if !@driver.uuid
        state_id = @driver.read_state if !state_id
        state_id = :unknown if !state_id

        # Translate into short/long descriptions
        short = state_id.to_s.gsub("_", " ")
        long  = I18n.t("vagrant.commands.status.#{state_id}")

        # If we're not created, then specify the special ID flag
        if state_id == :not_created
          state_id = Vagrant::MachineState::NOT_CREATED_ID

View on GitHub (pinned to 35f3160f4a)

Solutions

1. Re-run vagrant as the user listed in 'The UID used to create the VM was:'
2. Or recreate the VM under the current user: `vagrant destroy` (as the original user) then `vagrant up` as the intended account
3. For WSL/Windows interop, set the wsl_windows_access_* machine config/env option so the bypass applies to that data dir
4. Avoid `sudo vagrant`; fix the underlying permission problem instead

Example fix

# before — created as user 1000, now running under another account
$ sudo vagrant up   # -> VirtualBoxUserMismatch (original_uid: 1000, uid: 0)
# after — run as the creating user, or rebuild
$ vagrant destroy; vagrant up   # run WITHOUT sudo, as the original user

uid_file = File.read(File.join(project_dir, '.vagrant/machines/<name>/virtualbox/id')) rescue nil
# simpler: check owner of the .vagrant dir
owner_uid = File.stat(File.join(project_dir, '.vagrant')).uid
abort 'run vagrant as the user who created the VM' if owner_uid != Process.uid

def machine_owner_matches?(machine)
  machine.uid.nil? || machine.uid.to_s == Process.uid.to_s
end

When it happens

Trigger: Calling state (almost any vagrant command touching the machine: up, status, ssh, destroy) when the .vagrant data dir was created by a different OS user — e.g. running `sudo vagrant ...`, switching accounts, or a shared project directory used by two users.

Common situations: Running vagrant with sudo 'to fix' permission errors; project cloned/copied from another user's home; CI running under a different service account than the interactive user who first ran `vagrant up`; WSL setups where the VM was created from Windows but vagrant runs in WSL without the bypass env var.

Related errors

• Vagrant attempted to clean the machine folder for the machin
• No synced folder implementation is available for your synced
• Failed to create the following shared folder on the host sys
• The guest machine entered an invalid state while waiting for
• The home directory you specified is not accessible. The home

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