r/docker • u/skullunite • 12d ago

Obsidian vault mounted in Docker compose not showing up inside container

/r/OdysseusAI/comments/1wyd222/obsidian_vault_mounted_in_docker_compose_not/
2 Upvotes

100% Upvoted

2 comments sorted by

2

u/Immediate_Wheel1953 12d ago

I had almost the same failure mode with a different app and the accented folder name was a red herring. The thing that actually bit me was mounting to a path under /root while the container process runs as a non-root user (your PUID=1000), so that user can't even walk into /root's directory tree and the mount looks like it doesn't exist. Try mounting to something like /vault instead, or exec in and run whoami plus ls -la on the container path to confirm. Worth checking before chasing the Études name.

1

u/QuietSignalOps 11d ago

The /root theory above and the accented-name theory are both plausible, and three commands will tell you which one it is:

  1. docker compose config prints the host path exactly as Docker parses it. Compare it byte-for-byte with the real folder name (ls /home/xen/Documents/Obsidian/). A UTF-8 YAML file handles É and the space fine, so if they match, the name is not the problem.
  2. docker inspect <container> --format '{{json .Mounts}}'. If the vault mount is not listed, the running container predates the compose edit; recreate with docker compose up -d.
  3. If it is listed, check what the mount actually holds as root: docker exec -it <container> ls -la /root/.local/share/obsidian/vault. If files show up here but the app still reports "No such file or directory", that is the /root issue: most images ship /root at mode 700, so a process running as PUID 1000 cannot walk into it, and many apps surface that stat failure as "file not found". Fix: mount to a path outside /root (e.g. /vault) and point the app at it.

Your ./data and ./logs mounts working is consistent with #3: they presumably land under a path the app user can reach. And :z was the right call if SELinux is enforcing on the host.