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.

[cr-zhichen]

I’m experiencing the same issue.

Environment:

• Apple Silicon Mac
• OrbStack amd64 Ubuntu Resolute
• GNU tar 1.35

I encountered it while installing both mise and Homebrew. The archives download successfully, but GNU tar fails while creating nested directories.

For example, the mise installer fails with:

tar: mise/share: Cannot mkdir: Function not implemented
tar: mise/share/fish: Cannot mkdir: Function not implemented
tar: mise/share/fish/vendor_conf.d: Cannot mkdir: Function not implemented
tar: mise/bin: Cannot mkdir: Function not implemented
tar: mise/bin/mise: Cannot open: Function not implemented
tar: Exiting with failure status due to previous errors

Homebrew’s Portable Ruby extraction fails in the same way.

I specifically need an amd64 guest because one of my project dependencies, openctp-ctp==6.7.11.0, only provides x86_64 Linux wheels, so switching to an arm64 guest is not a viable workaround.

Using bsdtar works, which appears consistent with the original report. I’m happy to provide a diagnostic report or run additional tests if needed.