I’m having a problem bringing up a service with attached storage provided by the rancher-nfs driver. I’m 90% sure the problem is actually on the file server side (a NetApp appliance that I don’t administer), but since I have a well-constrained test case I’d like to discuss with the community to make sure I’m not barking up the wrong tree.
To reproduce the issue I’m seeing, follow these steps:
-
Build a simple container that has a volume directive in it:
$ cat Dockerfile
FROM ubuntu:16.04
RUN mkdir -p /mnt/rancher-nfs
VOLUME /mnt/rancher-nfs
$ docker build -t sometag .
$ docker run -it --rm sometag
root@c7c7a81b46ff:/# ll /mnt/rancher-nfs
total 0
drwxr-xr-x 2 root root 6 Nov 15 01:43 ./
drwxr-xr-x 1 root root 24 Nov 15 01:34 …/
Observe that the contaner’s /mnt/rancher-nfs volume is owned by root:root.
-
Launch a Rancher service using this container, with a rancher-nfs volume mapped to /mnt/rancher-nfs:
$ cat docker-compose.yml
version: ‘2’services:
ubuntu:
image: somerepo:sometag
tty: true
volume_driver: rancher-nfs
volumes:
- foovolume:/mnt/rancher-nfsvolumes:
foovolume:
driver: rancher-nfs
external: false$ rancher-compose up -d
Open a shell in one of the deployed containers and observe that /mnt/rancher-nfs is mounted to the NFS export, and that the /mnt/rancher-nfs directory is owned by root:root.
So far, so good. But now let’s make one simple change…now let’s make /mnt/rancher-nfs owned by a non-root user:
$ cat Dockerfile
FROM ubuntu:16.04
RUN mkdir -p /mnt/rancher-nfs && chown www-data /mnt/rancher-nfs <-- note chown command
VOLUME /mnt/rancher-nfs
Rebuild the container, push to registry, and tell the service to upgrade (or tear down the old one and start a new one, either way).
What ends up happening in this case, is that the rancher-nfs driver generates an error when trying to mount /mnt/rancher-nfs (see attached screenshot) and the service fails to start.