What causes "failed to get working directory" in hyperledger/fabric?

Restart the peer/process from an existing working directory.

failed to get working directory

Error message

failed to get working directory

What it means

moduleInfo saves the current working directory with os.Getwd() before chdir-ing into the chaincode path; if Getwd fails (e.g. the process's cwd was deleted), the wrapped 'failed to get working directory' error is returned.

Source

Thrown at core/chaincode/platforms/golang/platform.go:380

	}, nil
}

func regularFileExists(path string) (bool, error) {
	fi, err := os.Stat(path)
	switch {
	case os.IsNotExist(err):
		return false, nil
	case err != nil:
		return false, err
	default:
		return fi.Mode().IsRegular(), nil
	}
}

func moduleInfo(path string) (*ModuleInfo, error) {
	entryWD, err := os.Getwd()
	if err != nil {
		return nil, errors.Wrap(err, "failed to get working directory")
	}

	// directory doesn't exist so unlikely to be a module
	if err := os.Chdir(path); err != nil {
		return nil, nil
	}
	defer func() {
		if err := os.Chdir(entryWD); err != nil {
			panic(fmt.Sprintf("failed to restore working directory: %s", err))
		}
	}()

	// Using `go list -m -f '{{ if .Main }}{{.GoMod}}{{ end }}' all` may try to
	// generate a go.mod when a vendor tool is in use. To avoid that behavior
	// we use `go env GOMOD` followed by an existence check.
	cmd := exec.Command("go", "env", "GOMOD")
	cmd.Env = os.Environ()
	output, err := cmd.Output()

View on GitHub (pinned to 2736b63f8f)

Solutions

Restart the peer/process from an existing working directory.
Ensure the process's cwd exists and is accessible before invoking chaincode packaging.
Avoid deleting directories the peer process was started from.

Defensive patterns

Strategy: try-catch

Validate before calling

if _, err := os.Getwd(); err != nil {
	return fmt.Errorf("process cwd unusable: %w", err)
}

Try / catch

if _, err := golang.DescribeCode(path); err != nil {
	if strings.Contains(err.Error(), "failed to get working directory") {
		// restart peer from an existing directory
	}
}

Prevention

Start the peer from a stable, existing directory
Never delete the directory a long-running process was launched from
Monitor container mounts for the process cwd

When it happens

Trigger: Calling moduleInfo (via DescribeCode or NormalizePath) when the current working directory of the process has been removed or is inaccessible, making os.Getwd fail.

Common situations: Long-running peer processes whose startup directory was deleted, containers with unusual cwd setups, permission changes on ancestor directories.

Related errors

AI-assisted analysis of hyperledger/fabric@2736b63f8f (2026-09-04). Data as JSON: /api/errors/da9e5db1a72eedea. Report an issue: GitHub.