[Bug]: PeaNUT /config permission issue on Docker Desktop for macOS

[shamoon]

Describe the bug

I hit a confusing permissions issue running PeaNUT on Docker Desktop for macOS.

Compose setup:

peanut:
  image: brandawg93/peanut:latest
  container_name: peanut
  user: "1000:1000"
  ports:
    - 8580:8080
  volumes:
    - /Users/me/dev/homepage/apps/peanut:/config
  environment:
    - WEB_PORT=8080

PeaNUT kept logging:

PeaNUT cannot write to the config directory.
  Path:          /config
  Error:         EACCES: permission denied, access '/config'
  Process user:  uid=1000 gid=1000
  Directory:     uid=0 gid=0 mode=755

The confusing part was that the host directory looked writable. I tried the usual fixes:

mkdir -p /Users/me/dev/homepage/apps/peanut
sudo chown -R 1000:1000 /Users/me/dev/homepage/apps/peanut
chmod -R u+rwX /Users/me/dev/homepage/apps/peanut

I also tried running the container as my macOS user, 501:20, but PeaNUT still reported /config as uid=0 gid=0 mode=755.

I verified the bind mount was correct:

docker inspect peanut --format '{{range .Mounts}}{{println .Type .Source "->" .Destination}}{{end}}'

Output:

bind /Users/me/dev/homepage/apps/peanut -> /config

Testing with Alpine showed the weird behavior:

docker run --rm \
  --user 1000:1000 \
  -v /Users/me/dev/homepage/apps/peanut:/config \
  alpine sh -c 'ls -ldn /config; touch /config/test-write; ls -lan /config'

The directory showed as root:root 755, but the write could still succeed after host-side permission changes. PeaNUT, however, continued to fail its config check.

What finally fixed it was running chmod from inside a Linux container against the bind mount:

docker run --rm \
  -v /Users/me/dev/homepage/apps/peanut:/config \
  alpine sh -c 'chmod 777 /config; ls -ldn /config'

After that, restarting PeaNUT worked and it created settings.yml in the mounted config directory.

This seems like a Docker Desktop/macOS bind mount annoyingness. It would be helpful if the docs mentioned this workaround, or if PeaNUT’s permission check could attempt a real temporary write instead of relying on the reported directory ownership/mode.

Debug Output

n/a

Steps to reproduce

See above, simple compose on macOS Docker Desktop

Device Type

macOS

UPS Device

n/a

Last Working Version

No response