hashicorp/vagrant · error · VagrantPlugins::SyncedFolderSMB::Errors::SMBNameError

Vagrant is unable to setup a requested SMB share. An SMB sha

Error message

Vagrant is unable to setup a requested SMB share. An SMB share already
exists with the given name.

Share name: %{name}

Current path: %{existing_path}

Requested path: %{path}

What it means

SyncedFolderSMB::Errors::SMBNameError raised at plugins/hosts/windows/cap/smb.rb:88 in smb_prepare. For each folder Vagrant derives a deterministic name `vgt-<machine_id>-<md5(folder id)>` (data[:smb_id] defaults to it); if that share already exists in current_shares but its recorded Path — after File.expand_path and downcase — differs from the requested host path, it raises. Windows permits one share per name, and silently remapping would hide a real config change.

Source

Thrown at plugins/hosts/windows/cap/smb.rb:88

        def self.smb_prepare(env, machine, folders, opts)
          script_path = File.expand_path("../../scripts/set_share.ps1", __FILE__)

          shares = []
          current_shares = existing_shares
          folders.each do |id, data|
            hostpath = data[:hostpath].to_s

            chksum_id = Digest::MD5.hexdigest(id)
            name = "vgt-#{machine_id(machine)}-#{chksum_id}"
            data[:smb_id] ||= name

            # Check if this name is already in use
            if share_info = current_shares[data[:smb_id]]
              exist_path = File.expand_path(share_info["Path"]).downcase
              request_path = File.expand_path(hostpath).downcase
              if !hostpath.empty? && exist_path != request_path
                raise SyncedFolderSMB::Errors::SMBNameError,
                  path: hostpath,
                  existing_path: share_info["Path"],
                  name: data[:smb_id]
              end
              @@logger.info("skip creation of existing share name=#{name} id=#{data[:smb_id]}")
              next
            end

            @@logger.info("creating new share name=#{name} id=#{data[:smb_id]}")

            shares << [
              "\"#{hostpath.gsub("/", "\\")}\"",
              name,
              data[:smb_id]
            ]
          end
          if !shares.empty?
            uac_notified = false

View on GitHub (pinned to 35f3160f4a)

Solutions

1. Delete the stale share named in the error (elevated): `Remove-SmbShare -Name "<name>" -Force`, then re-run vagrant
2. Or fully `vagrant destroy` the machine so its shares are pruned, then `vagrant up`
3. Or change the Vagrantfile path back to the share's Current path printed in the error
4. With no machines running, bulk-clean: `Get-SmbShare vgt-* | Remove-SmbShare -Force`

Example fix

# before — project moved, old share still points at the old path
config.vm.synced_folder "C:/old/location", "/data", type: "smb"
# after — remove the stale share once, keep the new config
# powershell: Remove-SmbShare -Name "vgt-<machine>-<md5>" -Force
config.vm.synced_folder "C:/new/location", "/data", type: "smb"

# Before `vagrant up`, ensure no existing share conflicts with the intended path
# powershell:
#   $name = 'vgt-<machine-id>-<md5-of-folder-id>'
#   $s = Get-SmbShare -Name $name -ErrorAction SilentlyContinue
#   if ($s -and $s.Path -ne 'C:\intended\host\path') { Remove-SmbShare -Name $name -Force }
names = `powershell -NoProfile -Command "Get-SmbShare -Name 'vgt-*' | ForEach-Object { $_.Name + '=' + $_.Path }"`.split("\n")
conflict = names.find { |l| l.start_with?(expected_share_name) && !l.end_with?(intended_path.downcase) }
system("powershell -Command \"Remove-SmbShare -Name '#{conflict.split('=').first}' -Force\"") if conflict

begin
  env.machine_action(:up)
rescue VagrantPlugins::SyncedFolderSMB::Errors::SMBNameError => e
  puts "share '#{e.data[:name]}' already points at #{e.data[:existing_path]}, requested #{e.data[:path]}"
  # decide: remove stale share (Remove-SmbShare -Force) or revert path, then retry
  raise
end

When it happens

Trigger: A machine whose vgt-* share survives from a previous run while the Vagrantfile's host path for that folder changed: the project moved, the synced_folder path was edited, or machine state was restored with the same ID — so existing Path != requested path (empty hostpath is exempt via the `!hostpath.empty?` guard).

Common situations: Project directory moved/renamed between runs; Vagrantfile synced_folder path edited after first up; machine re-imported with the same ID; leftovers after a crashed destroy.

Related errors

• Exporting an SMB share failed! Details about the failure are
• Vagrant attempted to execute the capability '%{cap}' on the
• The synced folder type '%{type}' is reporting as unusable fo
• Vagrant failed to automatically start the SMB service. Ensur
• Exporting an SMB share failed! Details about the failure are

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