[Bug]: Virtiofs — untarring buildroot archives to a VirtioFS-mounted case-sensitive APFS volume produces corrupted symlinks

[9426224]

I have done the following

• I have searched the existing issues
• If possible, I've reproduced the issue using the 'main' branch of this project

Steps to reproduce

Steps to reproduce

1. On macOS, create or prepare a case-sensitive APFS volume and copy some tarball source archives (for example buildroot *.tar.xz / *.tar.gz) onto that volume.
2. Start a container from an Ubuntu 22.04 (x86) image on Apple Container and mount the case-sensitive APFS volume into the container using a bind/volume mount (this host → container mount ends up backed by VirtioFS with “Enable VirtioFS accelerated directory sharing” / default Apple container settings).
3. Inside the container, cd to the mounted directory and run tar -xf <archive>.tar.xz (or tar -xf <archive>.tar.gz) to extract the archive onto the VirtioFS mount.
4. Observe extracted files that were symlinks in the archive are created incorrectly (zero-byte files or filenames/targets replaced with question marks or otherwise corrupted). Extracting the same archive to a directory that sits on the container’s local filesystem (not the VirtioFS mount) succeeds and symlinks are created correctly.

Current behavior

When extracting archives (tar.xz / tar.gz) that contain symbolic links into a directory backed by VirtioFS (case-sensitive APFS host volume mounted into the container), tar reports permission/open errors for symlink entries and the filesystem ends up with zero-byte files or filenames full of question marks instead of valid symlinks.

Example from my case: an archive contained entries like

lrwxrwxrwx 1 root root 40 Dec 18 2021 snd_soc_apq8016_sbc.conf -> ../Qualcomm/apq8016-sbc/apq8016-sbc.conf

After extraction to the VirtioFS mount the extracted entry is corrupted (file of size 0 with no permissions or a name/target represented as ???????), while extracting the same archive to a local (non-virtiofs) directory inside the container works normally.

This behavior is effectively the same class of symptom described in an earlier report (issue #6277). ([GitHub](docker/for-mac#6277))

Expected behavior

Symbolic links inside the archive should be recreated correctly when extracted into a directory that is mounted from the host via VirtioFS. tar should not report permission denied for creating symlinks, and the extracted symlink entries should have the same link target and permissions as they do when extracted onto a non-VirtioFS filesystem.

Environment

- OS: macOS 26.2 (25C56)
- Xcode: /
- Container: container CLI version 0.9.0 (build: release, commit: 3e49dce)
- Container image: `ubuntu:22.04` (x86) 
- Host filesystem: case-sensitive APFS volume (created on the Mac and mounted into the container)
- Share mechanism: VirtioFS (host → container mount / volume)
- Archives tested: buildroot `*.tar.xz` and other `tar.gz`/`tar.xz` archives that contain symlinks
- Behaviour: extraction to local container filesystem (not VirtioFS) — OK; extraction to VirtioFS mount — symlinks corrupted

Relevant log output

- `tar` error example (representative):


tar: ./some/path/.bin/katex: Cannot open: Permission denied
...
---------- 1 root root 0 Apr 12 15:04 katex


- Example archive symlink (from an affected archive):


lrwxrwxrwx 1 root root 40 Dec 18 2021 snd_soc_apq8016_sbc.conf -> ../Qualcomm/apq8016-sbc/apq8016-sbc.conf


(After extraction to VirtioFS mount the entry appears as a zero-byte file or as corrupted name/target.)

Code of Conduct

• I agree to follow this project's Code of Conduct

[JaewonHur]

Hi @9426224
Could you share your MacOS version (i.e., sw_vers), and provide the minimal reproduce?

I'm on macOS 26.2 (25C56), and untar succeeded on my Mac.

I did follows:

diskutil apfs addVolume disk3 APFSX apfsx
diskutil mount apfsx
container run --rm -it -v /Volumes/apfsx:/root/apfsx --name test debian:bookworm

# In container
mkdir -p myvolume; cd myvolume; touch hello; ln -s hello symlink; cd ..
tar -cvf myvolume.tar.gz myvolume
cp myvolume.tar.gz /root/apfsx
cd /root/apfsx; tar xvf myvolume.tar.gz