Running uWSGI with supervisor in a docker container is giving permission denied

Question

I have Django app that I want to run with UWSGI in a Docker container using Supervisor.

I am using OSX so to successfully mount my OSX filesystem inside my boot2docker VM (so I can mount volumes with docker run -v /source/:/destination) I've had to use sshfs which I think is causing some strange permissions on my mounted filesystem.

I have two mounts on my boot2docker VM; one that points to my apps codebase and one that points to an arbitrary location on my host to write persistent logs to

Host: /Users/username/workspace/project --- > boot2docker: /home/docker/osx
Host: /containers/project               --- > boot2docker: /containers/project

I start my docker container with:

docker run -t -i -p 80 -v /home/docker/osx/project/www:/var/www -v /containers/project:/host image-name /bin/bash

My supervisor config for my app looks like this:

[program:app_name]
command=uwsgi --ini /var/www/wsgi/uwsgi.ini
directory=/var/www
autostart=true
autorestart=true
stdout_logfile=/host/logs/app-name.log
redirect_stderr=True

My usgi.ini looks like this:

[uwsgi]

http = :3041
chdir = /var/www
module = run.wsgi
uid = www-data
gid = 33
master = True
processes = 4
threads = 1
pidfile = /var/run/uwsgi.pid
touch-reload = /var/run/uwsgi.pid
logto = /host/logs/uwsgi.log

When I run my app with supervisorctl I get the following errors:

root@4237fd060a40:/var/www# supervisorctl
app_name               FATAL      Exited too quickly (process log may have details)
supervisor> start app_name
2014-06-15 10:22:16,559 INFO spawned: 'app_name' with pid 105
2014-06-15 10:22:16,633 INFO exited: app_name (exit status 1; not expected)
2014-06-15 10:22:17,658 INFO spawned: 'app_name' with pid 106
app_name: ERROR (abnormal termination)

And in the uWSGI logs I'm seeing:

[uWSGI] getting INI configuration from /var/www/run/uwsgi.ini
*** Starting uWSGI 1.9.10 (64bit) on [Sun Jun 15 10:22:22 2014] ***
compiled with version: 4.6.3 on 13 June 2014 15:25:05
os: Linux-3.14.1-tinycore64 #1 SMP Mon Jun 9 16:21:23 UTC 2014
nodename: 4237fd060a40
machine: x86_64
clock source: unix
detected number of CPU cores: 4
current working directory: /var/www
writing pidfile to /var/run/uwsgi.pid
detected binary path: /usr/local/bin/uwsgi
setgid() to 33
setuid() to 33
chdir(): Permission denied [core/uwsgi.c line 2121]

Running id -g www-data shows me that my gid is right and that www-data exists:

root@4237fd060a40:/var/www# id -g www-data
33

And inside my docker container the file permissions I'm seeing look like this:

root@4237fd060a40:/var/www# ll
total 76
drwxr-xr-x  1 10133 10000   578 Jun 15 09:55 ./
drwxr-xr-x 30 root  root   4096 Jun 15 09:52 ../
drwxr-xr-x  1 10133 10000   714 Jun 13 10:55 some_folder/
drwxr-xr-x  1 10133 10000  1292 Jun  9 11:29 some_file.py

So because I'm seeing uids and gids here, the files / folders are owned by a user that doesn't exist (they match up with my host OSX usernames uid and gid), and I'm getting the permission errors above because the www-data user doesn't have access to write to the mounted filesystem, which I can prove using su:

root@4237fd060a40:/var/www# su www-data
$ pwd
/var/www
$ touch test2
touch: cannot touch `test2': Permission denied

Makes sense so far, but when I try and write a file as root:

root@4237fd060a40:/var/www# touch test
root@4237fd060a40:/var/www# ll
total 76
...
-rw-r--r--  1 10133 10000     0 Jun 15 10:20 test

Writing a file works fine, and even has the right uid and gid.

So, I would have expected running uWSGI as root with this uwsgi.ini file:

[uwsgi]

http = :3041
chdir = /var/www
module = run.wsgi
uid = root
gid = 10000
master = True
processes = 4
threads = 1
pidfile = /var/run/uwsgi.pid
touch-reload = /var/run/uwsgi.pid
logto = /host/logs/uwsgi.log

Or as 10133 with this uwsgi.ini file:

[uwsgi]

http = :3041
chdir = /var/www
module = run.wsgi
uid = 10133
gid = 10000
master = True
processes = 4
threads = 1
pidfile = /var/run/uwsgi.pid
touch-reload = /var/run/uwsgi.pid
logto = /host/logs/uwsgi.log

Would work, but I'm getting no love:

[uWSGI] getting INI configuration from /var/www/run/uwsgi.ini
*** Starting uWSGI 1.9.10 (64bit) on [Sun Jun 15 10:30:05 2014] ***
compiled with version: 4.6.3 on 13 June 2014 15:25:05
os: Linux-3.14.1-tinycore64 #1 SMP Mon Jun 9 16:21:23 UTC 2014
nodename: 4237fd060a40
machine: x86_64
clock source: unix
detected number of CPU cores: 4
current working directory: /var/www
writing pidfile to /var/run/uwsgi.pid
detected binary path: /usr/local/bin/uwsgi
setgid() to 10000
*** WARNING: you are running uWSGI as root !!! (use the --uid flag) ***
chdir(): Permission denied [core/uwsgi.c line 2121]

And

[uWSGI] getting INI configuration from /var/www/run/uwsgi.ini
*** Starting uWSGI 1.9.10 (64bit) on [Sun Jun 15 10:30:36 2014] ***
compiled with version: 4.6.3 on 13 June 2014 15:25:05
os: Linux-3.14.1-tinycore64 #1 SMP Mon Jun 9 16:21:23 UTC 2014
nodename: 4237fd060a40
machine: x86_64
clock source: unix
detected number of CPU cores: 4
current working directory: /var/www
writing pidfile to /var/run/uwsgi.pid
detected binary path: /usr/local/bin/uwsgi
uWSGI running as root, you can use --uid/--gid/--chroot options
setgid() to 10000
setuid() to 10133
chdir(): Permission denied [core/uwsgi.c line 2121]

What am I missing?

Solution

I was seeing permission denied errors here because the guid didn't exist inside the container.

Changing the line guid=10000 to guid=root fixed it.

Comments

[Andy Shinn]

Have you tried copying / rsyncing your data over to the boot2docker host to eliminate SSHFS as the source of the problem?

[Chris McKinnel]

Hi Andy, yeah I have considered doing that but I need to have a mounted filesystem to enable "live editing" of the code-base for development. Having to create a new image every time some code has changed isn't acceptable for me.

[Chris McKinnel]

And when I say "live editing", I mean users of the container being able to develop in their own host environment and instantly see changes to the code-base reflected in their browser.

[Andy Shinn]

Gotcha. If you haven't already subscribed to github.com/dotcloud/docker/issues/4023, you may want to check it out.

[Phineas]

Is this considered safe?