GNU tar fails to extract nested directories in amd64 Rosetta machine

[sanchuanhehe]

Describe the bug

GNU tar 1.35 fails to extract archives containing nested directories inside an amd64 Ubuntu machine running through Rosetta. The first directory level is created, but creating the second level fails with Function not implemented.

The same archive extracts successfully with Python tarfile and bsdtar in the amd64 machine. The same GNU tar 1.35 test also succeeds in an arm64 Ubuntu machine under the same OrbStack installation.

To Reproduce

Create an amd64 Ubuntu Resolute machine on an Apple Silicon Mac, then run:

d=$(mktemp -d /tmp/tar-debug.XXXXXX)
mkdir -p "$d/src/a/b" "$d/out"
touch "$d/src/a/b/test"
tar -C "$d/src" -cf "$d/test.tar" .
tar -C "$d/out" -xf "$d/test.tar"

Output:

/usr/bin/tar: ./a/b: Cannot mkdir: Function not implemented
/usr/bin/tar: ./a/b/test: Cannot open: Function not implemented
/usr/bin/tar: Exiting with failure status due to previous errors

The failure is reproducible after a clean OrbStack restart with about 10 GiB of available VM memory.

Control tests in the same amd64 machine:

• mkdir -p creates the same nested directory structure successfully.
• Python tarfile.extractall() extracts the archive successfully.
• bsdtar extracts the archive successfully.
• GNU tar still fails with --no-same-owner --no-same-permissions, --overwrite, --no-overwrite-dir, and --delay-directory-restore.

An identical test succeeds with GNU tar 1.35 in an arm64 Ubuntu Resolute machine under the same OrbStack installation. This isolates the failure to the amd64/Rosetta execution path rather than the archive, filesystem, Ubuntu release, glibc version, or GNU tar version alone.

Expected behavior

GNU tar should extract the nested a/b/test path successfully, as it does in the native arm64 machine and as other archive implementations do in the amd64 machine.

Diagnostic report (REQUIRED)

https://orbstack.dev/_admin/diag/orbstack-diagreport_2026-07-10T05-41-40.856929Z.zip

Screenshots and additional context (optional)

• OrbStack: 2.2.1 (2020100), commit 0e182b501fcd9e05b99ffb363fce03610390c400
• Host: macOS 26.5.2 (25F84), arm64
• Guest: Ubuntu Resolute, amd64
• OrbStack kernel: 7.0.11-orbstack-00360-gc9bc4d96ac70
• Guest glibc: Ubuntu GLIBC 2.43-2ubuntu2
• GNU tar: 1.35
• Guest root filesystem: Btrfs
• Test extraction filesystem: tmpfs (/tmp)
• Rosetta binfmt entry is enabled.

strace records only the translated process exit (+++ exited with 2 +++) and does not expose the syscalls issued inside Rosetta, so the exact translated syscall returning ENOSYS could not be observed from the guest.