symlinks are unloved in docker

[wjcarpenter 4]

I temporarily forgot about this, so maybe it will help someone else to avoid wasting a little time. Docker is naive about symlinks on the host system. I wanted to put my recordings on a separate drive, so I made a symlink to the programdata/data/livetv/recordings/ directory. Inside docker, the symlink is not visible, so emby fails with "can't find it". Like I said, I knew all that, and I just forgot because I wanted to waste some weekend time.  (I changed my strategy to putting all of the emby volumes on that other drive and mapping them into the container.)

[Luke 37218]

Hi, thanks for sharing your experience on this. Are you positive that docker is symlink naive? It could be dotnet runtime related.

[wjcarpenter 4]

I don't know if there are additional dotnet considerations (I doubt it), but I know it's a problem with Docker and host system symlinks. (I first became aware of this a couple years ago when mapping USB ports into a container: https://hackaday.io/page/13294-solved-docker-udev-usb-naming) The Linux environment inside the container recognizes the symlink, of course, but when it tries to dereference it, it points to a path on the host system. That path would only exist by coincidence in the container environment. You could get around the problem by making the symlinks inside the container environment, but I didn't want to make any modifications there beyond what I could map in with Docker.

[Q-Droid 670]

It makes perfect sense. Symlinks may (should) work in Docker if the reference is relative to their location and within the container side path of the bind mount or Docker volume. Otherwise they could pose a security problem allowing an application access to storage outside of the scope defined for the container.