What causes "error reading from STDIN: %w" in docker/cli?

Ensure the piped source completes successfully before stdin closes (check the producer's exit code).

error reading from STDIN

Error message

error reading from STDIN: %w

What it means

Returned by readConfigData() when stdin ('-') is the source for `docker config create` and io.ReadAll on the limited stdin reader returns an error (cli/command/config/create.go:113-116). The reader is wrapped with io.LimitReader(in, 2*maxConfigSize); an I/O error during the read (not emptiness, which is a separate check) produces this wrapped error.

Solutions

Ensure the piped source completes successfully before stdin closes (check the producer's exit code).
Avoid piping from a command that may fail or be interrupted mid-stream.
If the data is on disk, pass the file path directly instead of '-'.
Verify the data is under 2*maxConfigSize to avoid truncation-related surprises.

Example fix

# before
generate-config | docker config create mycfg -   # generate-config crashes mid-pipe
# after
set -o pipefail
generate-config > /tmp/cfg.json && docker config create mycfg /tmp/cfg.json

Defensive patterns

Strategy: try-catch

Try / catch

// If you script `docker config create NAME -`, capture the producer exit and retry.
if ! produce | docker config create mycfg -; then
    if [ ${PIPESTATUS[0]} -ne 0 ]; then echo "producer failed"; fi
fi

Prevention

Use set -o pipefail so a crashing producer is visible.
Prefer writing to a temp file and creating from it when the producer is unreliable.

When it happens

Trigger: Running `docker config create NAME -` and piping/typing input where the read itself fails: a broken pipe, premature close of stdin, or a terminal EOF error. Note: empty stdin yields a separate 'data is empty' error, not this one.

Common situations: Pipe source exits/crashes mid-stream (SIGPIPE), redirecting from a file descriptor that is closed, or running interactively without supplying input correctly. Input larger than 2*maxConfigSize (2 MB) is silently truncated, not errored, so the error here is specifically an OS-level read failure.

Related errors

AI-assisted analysis of docker/cli@4f84911bfe (2026-08-07). Data as JSON: /api/errors/4d4021efffda0fb5. Report an issue: GitHub.

Appendix: source

Thrown at cli/command/config/create.go:115

}

// maxConfigSize is the maximum byte length of the [swarm.ConfigSpec.Data] field,
// as defined by [MaxConfigSize] in SwarmKit.
//
// [MaxConfigSize]: https://pkg.go.dev/github.com/moby/swarmkit/v2@v2.0.0-20250103191802-8c1959736554/manager/controlapi#MaxConfigSize
const maxConfigSize = 1000 * 1024 // 1000KB

// readConfigData reads the config from either stdin or the given fileName.
//
// It reads up to twice the maximum size of the config ([maxConfigSize]),
// just in case swarm's limit changes; this is only a safeguard to prevent
// reading arbitrary files into memory.
func readConfigData(in io.Reader, fileName string) ([]byte, error) {
	switch fileName {
	case "-":
		data, err := io.ReadAll(io.LimitReader(in, 2*maxConfigSize))
		if err != nil {
			return nil, fmt.Errorf("error reading from STDIN: %w", err)
		}
		if len(data) == 0 {
			return nil, errors.New("error reading from STDIN: data is empty")
		}
		return data, nil
	case "":
		return nil, errors.New("config file is required")
	default:
		// Open file with [FILE_FLAG_SEQUENTIAL_SCAN] on Windows, which
		// prevents Windows from aggressively caching it. We expect this
		// file to be only read once. Given that this is expected to be
		// a small file, this may not be a significant optimization, so
		// we could choose to omit this, and use a regular [os.Open].
		//
		// [FILE_FLAG_SEQUENTIAL_SCAN]: https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea#FILE_FLAG_SEQUENTIAL_SCAN
		f, err := sequential.Open(fileName)
		if err != nil {
			return nil, fmt.Errorf("error reading from %s: %w", fileName, err)

View on GitHub (pinned to 4f84911bfe)