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

Exporting an SMB share failed! Details about the failure are

Error message

Exporting an SMB share failed! Details about the failure are shown
below. Please inspect the error message and correct any problems.

Host path: %{host}

Stderr: %{stderr}

Stdout: %{stdout}

What it means

SyncedFolderSMB::Errors::DefineShareFailed raised at plugins/hosts/darwin/cap/smb.rb:107 in smb_export: each share is defined by running `sudo /usr/sbin/sharing -a <hostpath> -S <smb_id> -s 001 -g 000 -n <name>`; any non-zero exit raises with the host path plus the tool's stderr/stdout. The smb_id is a deterministic `vgt-<machine>-<md5>` name.

Source

Thrown at plugins/hosts/darwin/cap/smb.rb:107

            name = "vgt-#{machine_id(machine)}-#{chksum_id}"
            data[:smb_id] ||= name

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

            cmd = [
              "/usr/bin/sudo",
              "/usr/sbin/sharing",
              "-a", hostpath,
              "-S", data[:smb_id],
              "-s", "001",
              "-g", "000",
              "-n", name
            ]

            r = Vagrant::Util::Subprocess.execute(*cmd)

            if r.exit_code != 0
              raise VagrantPlugins::SyncedFolderSMB::Errors::DefineShareFailed,
                host: hostpath.to_s,
                stderr: r.stderr,
                stdout: r.stdout
            end
          end
        end

        # Generates a unique identifier for the given machine
        # based on the name, provider name, and working directory
        # of the environment.
        #
        # @param [Vagrant::Machine] machine
        # @return [String]
        def self.machine_id(machine)
          @@logger.debug("generating machine ID name=#{machine.name} cwd=#{machine.env.cwd}")
          Digest::MD5.hexdigest("#{machine.name}-#{machine.provider_name}-#{machine.env.cwd}")
        end
      end

View on GitHub (pinned to 35f3160f4a)

Solutions

  1. Check Stderr in the error — `sharing` prints its refusal reason there
  2. Verify the Host path from the error exists and is readable (`ls <host path>`); remount the volume if needed
  3. List existing definitions with `sharing -l` and remove stale/conflicting ones (`sudo sharing -r <name>`)
  4. Fix the Vagrantfile path and `vagrant reload`

Example fix

# before — host path that does not exist
config.vm.synced_folder "/Volumes/Backup/data", "/data", type: "smb"
# after — real, mounted host path
config.vm.synced_folder "/Users/me/data", "/data", type: "smb"
Defensive patterns

Strategy: validation

Validate before calling

# Verify every SMB host path exists before vagrant defines shares
Dir.glob("*").each { } # placeholder for load order
["/Users/me/data"].each do |p|
  abort "SMB host path missing: #{p}" unless File.directory?(File.expand_path(p))
end
# and check for stale definitions: `sharing -l | grep vgt-`

Try / catch

begin
  env.machine_action(:up)
rescue VagrantPlugins::SyncedFolderSMB::Errors::DefineShareFailed => e
  puts "share definition refused for #{e.data[:host]}:\n#{e.data[:stderr]}"
  # check existence/permissions of host path, remove stale `sharing -l` entries, retry
  raise
end

Prevention

When it happens

Trigger: Preparing SMB synced folders on macOS where the `sharing` tool refuses the definition: host path does not exist or is not a real absolute path, the share name/id collides with a stale definition, or file-sharing backend rejects the flags.

Common situations: host_path typo or on an unmounted external volume; path contains characters `sharing` rejects; a stale vgt-* share from a crashed run occupying the smb_id; SMB service half-disabled after an OS update.

Related errors

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