Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
eliasp opened this issue Oct 9, 2013 · 4 comments
Closed

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

eliasp opened this issue Oct 9, 2013 · 4 comments
Milestone

Comments

@eliasp
Copy link
Contributor

@eliasp eliasp commented Oct 9, 2013

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
Copy link
Contributor

@shykes shykes commented Nov 27, 2013

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
Copy link
Contributor

@crosbymichael crosbymichael commented Nov 27, 2013

+1 on handling the mounts ourself

@vieux
Copy link
Contributor

@vieux vieux commented Nov 28, 2013

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

@crosbymichael
Copy link
Contributor

@crosbymichael crosbymichael commented Feb 3, 2014

This has been fixed, verified using your example.

cpuguy83 pushed a commit to cpuguy83/docker that referenced this issue May 25, 2021
ipam/allocator_test: Test pool double-release behavior
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants