Chmod in Dockerfile: No such file or directory

Question

I try to build a Jupyterhub Docker Image and cannot use chmod on the volumes. My Dockerfile looks like this:

FROM jupyterhub/jupyterhub:latest

RUN pip install --no-cache \
    oauthenticator \
    dockerspawner \
    jupyterhub-nativeauthenticator


COPY jupyterhub_config.py /srv/jupyterhub/jupyterhub_config.py

WORKDIR /srv/jupyterhub
VOLUME /srv/jupyterhub/shared_data

RUN chmod 777 /srv/jupyterhub/shared_data

building this leads to the following error: > [6/6] RUN chmod 777 /srv/jupyterhub/shared_data: 0.118 chmod: cannot access '/srv/jupyterhub/shared_data': No such file or directory

Why is this and how can I fix it?

Answer 1

You should entirely delete that RUN line. Also consider deleting the VOLUME line before it.

From a security point of view, changing a directory (or anything) to mode 0777 is almost never considered a best practice. It allows any user to overwrite any other user's content; "overwrite" could include subtle changes to content or injecting malware into binaries.

In the case of a Docker container, there will be only a single process inside the container, so there's no reason to use an actively insecure setup. Leave the default file mode of 0755 (writable only by the owner) and make sure the container user is correct. Since this directory will eventually be a volume mount, you can figure out what (numeric) user ID owns the host directory

ls -lnd ./shared_data

and then launch the container as that specific numeric user ID.

docker run -u 1001 -v "$PWD/shared_data:/srv/jupyterhub/shared_data" ...

With this volume mount, the container directory is completely replaced by the host directory, including its ownership and permission. That means that, ignoring the error, the RUN chmod command still won't have an effect because a different directory will replace it. You can't make changes to the eventual mounted directory from the Dockerfile.

The volume mount also doesn't require a Dockerfile VOLUME directive. It's not impossible that the VOLUME is causing the specific error you're seeing here. The most obvious effect of VOLUME is to prevent any further changes to the named directory in the image, so again the RUN chmod won't have an effect; its second most obvious effect will be to leak anonymous volumes. Unless you're clear on what VOLUME does and why you want it, it's almost always safe to just delete that line.