'run' fails, if volume's target path contains a symlink

[eliasp]

When the target path of a volume contains a symlink, 'docker run' will fail:

Fail:

docker -D run -i -t -v /var/run/something lopter/raring-base /bin/bash

Success:

docker -D run -i -t -v /run/something lopter/raring-base /bin/bash

/var/run is a symlink pointing to /run, so as long as one doesn't use the path containing a symlink for the volume, everything is fine, otherwise it refuses to start like this:

lxc-start: Permission denied - failed to mount '/var/lib/docker/volumes/d3f49322202c7a4471f45722797a2d9cddcebf5a6f4614eb02fc93a7269550f9/layer' on '/usr/lib/x86_64-linux-gnu/lxc///var/run/something'
lxc-start: failed to setup the mount entries for '76e81c1655cb22d05e9f02f915bb83e1244b18c3769e63878a369157b3f36579'
lxc-start: failed to setup the container
lxc-start: invalid sequence number 1. expected 2
lxc-start: failed to spawn '76e81c1655cb22d05e9f02f915bb83e1244b18c3769e63878a369157b3f36579'

Version information:

Client version: 0.6.3
Go version (client): go1.1.2
Git commit (client): b0a49a3
Server version: 0.6.3
Git commit (server): b0a49a3
Go version (server): go1.1.2
Last stable version: 0.6.3

[shykes]

This seems to be tied to the behavior of lxc-start.

If we decide to change it, we will need to setup all mount-binds ourselves instead of relying on the generated lxc configuration as we do currently. It makes sense to do this since we are planning to make lxc an optional driver anyway, and we probably want to handle mount-binds separately from the execution driver.

cc @crosbymichael @vieux @creack

[crosbymichael]

+1 on handling the mounts ourself

[vieux]

+1 also, I we will have to do it in any case

[crosbymichael]

This has been fixed, verified using your example.