Technology · PRACTICAL GUIDE
curl error 23? Prove whether the file, pipe or wrapper rejected the output
“Failure writing output to destination” is a local write failure, not proof that the server or network failed. Preserve the command and status, separate a file sink from a pipeline, then repair only the destination that actually refused the bytes.
curl exit 23 means received data could not be written to a local file or a write callback rejected it. The message identifies a write boundary, not its cause: a downstream command may have intentionally stopped reading, a file path may not exist, a filesystem may be full, or a wrapper may be using a different temporary path.
Do not begin with sudo, reinstalling curl or suppressing stderr. Save the exact command and both pipeline statuses, then rerun the same URL once with a controlled file sink. That split tells you whether to inspect the file destination or the consumer on the right side of the pipe.
Freeze the command and classify the destination
Copy the exact command before editing it. Record curl --version, type -a curl, the URL host, options that choose output, redirects, redirections and every program in the pipeline. If a script invoked curl, capture that line and its working directory.
In Bash, run the failing pipeline without adding a new consumer and immediately record ${PIPESTATUS[@]}. A zero status from the last command can otherwise hide curl’s 23. Decide whether the intended result was a complete file, a complete stream, or only an early match.
Use one controlled file-sink test
Repeat the same request once with --output to a new file in a directory you own. Keep --location or authentication options unchanged, but do not pipe the body through head, grep or an installer. Preserve headers or verbose output separately so they cannot corrupt the artifact.
If the controlled file completes, the network path and curl’s basic file writer worked for that request; investigate the original downstream consumer or wrapper. If it fails, keep the warning printed immediately before code 23 and inspect the target path before retrying.
Audit a real file destination
Verify that the parent directory exists and is the directory you think the shell selected. Check available blocks and inodes on that exact filesystem, then test creation of a small temporary file as the same user. Do not infer access from ownership of a different directory.
For -o with a nested path, create only the intended parents or use --create-dirs when that behavior is explicitly wanted. Check whether the target is a symlink, read-only mount, container bind mount or sandbox-inaccessible location before broadening permissions.
Audit a pipeline or early-closing reader
Commands such as head and grep -q may exit as soon as they have enough input. The kernel then reports a broken pipe to the writer; curl cannot know whether that early close was intentional. If partial reading is the design, handle curl’s and the consumer’s statuses explicitly and document that the full body is not retained.
If later steps need the full payload, do not mask 23. Download to a temporary file, verify it, and then run the consumer on that file. This separates transfer completeness from parsing and prevents an installer or checksum step from accepting a truncated stream.
Check wrappers, repair one cause and verify
When only a packaged or embedded curl fails, compare the actual executable and its confinement with /usr/bin/curl; do not uninstall a package merely because another user’s case involved Snap. Also inspect the wrapper’s temporary directory and output filename rather than the visible outer command alone.
After one narrow repair, rerun once. Confirm curl’s status, the consumer’s status, the final size and—when the publisher provides one—the checksum or signature. Remove partial files that could be mistaken for a successful download and record which boundary actually failed.
