Named container workaround fails when container copies data into it

[oxisto]

This project currently sets up an empty directory as a workaround for a named container but that actually fails when the container tries to copy files into this directory. This can be seen when running a Wordpress container with a named volume.

docker-compose.yml

version: '3.8'
        
services:
  wordpress:
    image: wordpress:latest
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress
      WORDPRESS_DB_NAME: wordpress
    volumes:
      - wordpress_data:/var/www/html

this results in

wordpress: Error: internalError: "failed to change directory to '/var/www/html' Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory""

[Mcrich23]

I believe #42 fixes this

[thromel]

I reproduced a related named-volume failure on container-compose 1.0.0 with container 1.0.0. The current workaround also looks stale now that container run -v data:/data ... supports native named volumes.

Environment:

- OS: macOS 26.5.1 (25F80)
- Xcode: 26.5 (17F42)
- container: 1.0.0 (release, commit ee848e3)
- container-compose: 1.0.0 installed via Homebrew
- Architecture: arm64

Repro:

services:
  namedonly:
    image: busybox:latest
    volumes:
      - data:/data
    command: ["sh", "-c", "echo NAMED_OK > /data/named.txt && cat /data/named.txt"]

volumes:
  data:

Run:

container-compose --file compose.yml up -d namedonly

Observed:

Warning: Volume source 'data' appears to be a named volume reference. The 'container' tool does not support named volume references in 'container run -v' command. Linking to /Users/romel/.containers/Volumes/feature-isolation/data instead.
...
failed to find target executable sh

The failed service was not left around for inspection.

By contrast, native container named volumes worked directly:

container run --rm -v data:/data busybox:latest sh -c 'echo direct > /data/direct.txt && cat /data/direct.txt'
container run --rm -v data:/data busybox:latest sh -c 'cat /data/direct.txt'

Output:

direct
direct

So I think the fix should now be to stop rewriting named volumes to ~/.containers/Volumes/... and pass named volume mounts through to container directly where possible.

[ryan106]

This looks fixed by #119 too — I tested the exact WordPress repro from this issue against current main:

services:
  wordpress:
    image: wordpress:latest
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress
      WORDPRESS_DB_NAME: wordpress
    volumes:
      - wordpress_data:/var/www/html
volumes:
  wordpress_data:

container-compose up -d wordpress now starts and reaches running state cleanly — no more failed to change directory to '/var/www/html' crash. Matches the PR's own commit message ("Add named volume destination regression coverage"). Looks resolved.

[thromel]

This appears resolved by #119. Ryan validated the original WordPress named-volume repro against current main and confirmed it now starts cleanly without the /var/www/html failure. I do not have permission to close this issue because it was opened by another user, so a maintainer will need to close it as completed.