`sbx cp` fails with tar stream errors and leaves truncated files on Ubuntu 24.04 GCE VM

[flybae]

Summary

sbx cp fails when copying regular files from an Ubuntu 24.04 GCE host into a shell sandbox.

This is reproducible with synthetic random data and does not depend on any application repository, database, cloud storage bucket, or bootstrap script.

In one run, even a 1 MiB file failed with tar: Unexpected EOF in archive and left a truncated destination file inside the sandbox.

Environment

• Google Compute Engine VM
• Machine type: n2-standard-4
• OS: Ubuntu 24.04.4 LTS amd64
• Kernel: 6.17.0-1013-gcp
• Nested virtualization: enabled
• KVM modules loaded: kvm_intel, kvm
• Package: docker-sbx 0.28.3-1~ubuntu.24.04~noble
• sbx client/server: v0.28.3 8d114184e520cf5744502f187faf90342af599e5
• sbx diagnose: 7 passed

Example VM creation and ssh login command:

gcloud compute instances create sbx-cp-repro \
  --zone=asia-northeast1-a \
  --machine-type=n2-standard-4 \
  --image-family=ubuntu-2404-lts-amd64 \
  --image-project=ubuntu-os-cloud \
  --enable-nested-virtualization \
  --boot-disk-size=50GB

gcloud compute ssh sbx-cp-repro --zone=asia-northeast1-a

Reproduction

# On a fresh Ubuntu 24.04 amd64 GCE VM with nested virtualization enabled:

curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh
sudo apt-get update
sudo apt-get install -y docker-sbx
sudo usermod -aG kvm "$USER"

# Start a new shell/session if needed so the group change applies.
sbx login

sbx version
sbx diagnose

mkdir -p "$HOME/sbx-cp-repro-mount"
sbx create --name sbx-cp-repro shell "$HOME/sbx-cp-repro-mount"
sbx ls

src=/tmp/sbx-cp-repro-1m.bin
dst=/tmp/sbx-cp-repro-1m.copy.bin

rm -f "$src"
sbx exec -u root sbx-cp-repro -- rm -f "$dst" || true

dd if=/dev/urandom of="$src" bs=1M count=1
sha256sum "$src"
wc -c "$src"

sbx cp "$src" "sbx-cp-repro:$dst"

sbx exec -u root sbx-cp-repro -- bash -lc "
  ls -lh '$dst' || true
  wc -c '$dst' || true
  sha256sum '$dst' || true
"

Expected behavior

sbx cp should copy the file successfully.

The destination file should have the same size and SHA-256 hash as the source.

If the copy fails, it should not leave a truncated destination file behind.

Actual behavior

For a 1 MiB file:

ERROR: tar extract failed: tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

The destination file was left behind but truncated:

source bytes:      1048576
destination bytes: 1048064
sha256 match:      no

Larger files also fail, sometimes with a different tar stream error. For example, a 64 MiB file failed with:

Can't add file /tmp/sbx-cp-size-64m.bin to tar: io: read/write on closed pipe
Can't close tar writer: io: read/write on closed pipe
ERROR: write tar stream: write unix @->/home/<user>/.local/state/sandboxes/sandboxes/sandboxd/docker.sock: write: broken pipe

That run also left a truncated destination file:

source bytes:      67108864
destination bytes: 52801536
sha256 match:      no

Notes

The visible error varies between the receiver-side tar extraction error and the sender-side broken pipe error, but both appear to be the same class of failure: the sbx cp tar stream is interrupted and the sandbox can retain a partial destination file.

[mkeller-ergon]

Also encountering this problem on Windows 11 host. Very small files copy correctly, but from around 1MB it fails every time with the EOF error.