gastownhall/beads · error

inspecting remote target %s: %w

Error message

inspecting remote target %s: %w

What it means

classifyResetDataRemote wraps an unexpected os.ReadDir failure while inspecting the local filesystem path behind a file-backed Dolt remote, prior to clearing it. It is only returned for errors that are not IsNotExist (absence maps to resetDataFileAbsent), so it means the directory exists but could not be read — typically a permissions problem.

Source

Thrown at cmd/bd/dolt_remote_reset_data.go:70

// git+file:// at push time) or a native Dolt file store: a bare git repo
// takes the git-backed path, a directory with an nbs manifest is a file
// store, and a missing or empty target has nothing to reset. A non-empty
// target that is neither is an error — reset-data must not clear a
// directory it cannot identify.
func classifyResetDataRemote(url string) (resetDataKind, error) {
	if doltutil.IsGitProtocolURL(url) {
		return resetDataGitBacked, nil
	}
	path, isFile := resetDataFilePath(url)
	if !isFile {
		return resetDataUnsupported, nil
	}
	entries, err := os.ReadDir(path)
	if os.IsNotExist(err) {
		return resetDataFileAbsent, nil
	}
	if err != nil {
		return 0, fmt.Errorf("inspecting remote target %s: %w", path, err)
	}
	if len(entries) == 0 {
		return resetDataFileAbsent, nil
	}
	if isBareGitRepoDir(path) {
		return resetDataGitBacked, nil
	}
	if _, err := os.Stat(filepath.Join(path, "manifest")); err == nil {
		return resetDataFileStore, nil
	}
	return 0, fmt.Errorf("remote target %s is non-empty but is neither a bare git repository nor a Dolt file store (no manifest); refusing to clear it", path)
}

// resetDataFilePath extracts the local filesystem path from a file:// URL or
// a bare absolute path, reporting whether url is file-backed at all.
func resetDataFilePath(url string) (string, bool) {
	if strings.HasPrefix(url, "file://") {
		return strings.TrimPrefix(url, "file://"), true

View on GitHub (pinned to 71377f2769)

Solutions

1. Fix permissions on the remote target directory (chmod/chown) so the current user can list it
2. Confirm the path is a directory, not a regular file (ls -la)
3. Re-run as the user that owns the Dolt remote store, or move the store to a location you control

Example fix

// before
$ bd dolt remote reset-data  # permission denied on /srv/dolt/repo
// after
$ sudo chown -R $USER /srv/dolt/repo && bd dolt remote reset-data

if info, err := os.Stat(path); err != nil || !info.IsDir() {
    return fmt.Errorf("remote target %s is not an accessible directory", path)
}

cls, err := classifyResetDataRemote(path)
if err != nil {
    return fmt.Errorf("check permissions on %s before reset-data: %w", path, err)
}

When it happens

Trigger: bd dolt remote reset-data against a file:// remote whose directory exists but cannot be listed: permission denied, path is actually a file, or an I/O error during ReadDir.

Common situations: Remote directory owned by another user (e.g. created by a Dolt server or root); running bd under a different account in CI; a file where a directory was expected after manual cleanup.

Related errors

• reading remote store %s: %w
• dolt path is not executable
• creating .bd-dolt-ok marker: %w
• failed to remove Dolt database: %w
• remote target %s is non-empty but is neither a bare git repo

AI-assisted analysis of gastownhall/beads@71377f2769 (2026-08-30). Data as JSON: /api/errors/17d1e50eef74f67a. Report an issue: GitHub.