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

Containers don't work in Ubuntu due to permission errors #65

Closed
hamishwillee opened this issue Jul 27, 2017 · 14 comments
Closed

Containers don't work in Ubuntu due to permission errors #65

hamishwillee opened this issue Jul 27, 2017 · 14 comments
Assignees
Labels

Comments

@hamishwillee
Copy link
Contributor

As per PX4/PX4-Devguide#232 ...
I followed the instructions in devguide here, setting up docker in a clean Ubuntu 16.04 running on a VM (in Windows). Including post instructions to ensure I didn't have to execute docker as sudo.

I added /src dir and cloned Firmware in it. I can see that the parent above src belongs to root, and that src and below belong to my logged in user (via ls -la)

Then I tried to run the image in our docs:

xhost +
docker run -it --privileged \
-v <src_to_local_firmware>:/src/firmware/:rw \
-v /tmp/.X11-unix:/tmp/.X11-unix:ro \
-e DISPLAY=:0 \
-p 14556:14556/udp \
--name=px4_ros_sim px4io/px4-dev-ros:2017-05-31 bash

This "worked". I can log in and see /src/firmware, and the contents I have cloned. When I try to run make posix_sitl_default gazebo I get permission errors because docker can't create the build directory. The reason being that docker sets itself up as root user by default, which does not appear to have access.

If I go back to ubuntu and make access on the git tree "open" (e.g. chmod -R 7777 .) then I can build from docker and everything works. However this is a pretty bad recommendation to give users.

I have tried to send in another user via the -u flag (e.g. my current VM host user id "1000"). This does not work (user is not found). I tried the flag with the user's name too, but got told there is a missing password file. I think the problem is that the VM does not know about any users outside of itself other than root.

Any suggestions on "right way to fix". I'm hoping for instructions that don't require a user to do anything to their machine other than run a docker command.


FYI, this is the setup script:

# Install Docker CE for Ubuntu script - for Xenial 16.04 (LTS)
## https://docs.docker.com/engine/installation/linux/docker-ce/ubuntu/

##uninstall old versions
sudo apt-get remove docker docker-engine docker.io -y
##Update the apt package index:
sudo apt-get update
##Install packages to allow apt to use a repository over HTTPS:
sudo apt-get install apt-transport-https ca-certificates curl software-properties-common -y
## Add Docker’s official GPG key:
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
##Verify that the key fingerprint is 9DC8 5822 9FC7 DD38 854A E2D8 8D81 803C 0EBF CD88.
sudo apt-key fingerprint 0EBFCD88
##We're not doing any actual verification!
## Set up stable repository
sudo add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"

##Update the apt package index.
sudo apt-get update
##Install the latest version of Docker CE. Any existing installation of Docker is replaced.
sudo apt-get install docker-ce -y

# Create the docker group and add your user:
sudo groupadd docker
sudo usermod -aG docker $USER

Then restarted and verified using docker run hello-world

@dagar
Copy link
Member

dagar commented Jul 27, 2017

This is what I created for the CI system. https://github.com/PX4/Firmware/blob/master/Tools/docker_run.sh#L47

The important part is -e LOCAL_USER_ID="$(id -u)" which creates a user in the container with the same UID as your user on the host. This solves the file permission issues.

@dagar
Copy link
Member

dagar commented Jul 27, 2017

You can also use it locally.

./Tools/docker_run.sh 'make posix_sitl_default'

@dagar
Copy link
Member

dagar commented Aug 2, 2017

Resolved or do we need to do something else here?

@hamishwillee
Copy link
Contributor Author

Hi Daniel,
I haven't had an opportunity to test this yet. I'll set as closed and reopen if it isn't sufficient once I'm back in business.
Thanks!

@Stifael Stifael reopened this Sep 25, 2017
@Stifael
Copy link

Stifael commented Sep 25, 2017

I am still struggling with just
make posix_sitl_default gazebo within the container. I added the id, and I can build posix_sitl_default, but I cannot run it with gazebo

@Stifael
Copy link

Stifael commented Sep 25, 2017

would be great if we can get the integration documentation up to a state where ppl can test the integration tests locally without going through a lot of research how to to do that. Right now I think it would be even better to remove the documentation for integration tests entirely, since it does not represent the current state at all.

@JonasVautherin
Copy link

JonasVautherin commented Sep 25, 2017

About the permissions problem. Why having a user in the containers? I am usually running everything as root inside the docker containers.

Anyway, using a user called "user" with the px4-dev-ros image, I have observed that mounting my "Firmware" folder into /home/user/Firmware would cause permission issues, whereas mounting it into /home/Firmware is always fine. Not sure why, though. Maybe you can try that?

@dagar
Copy link
Member

dagar commented Sep 25, 2017

@JonasVautherin the common use case is a developer or CI system that has the source outside of the container and then mounts it as a volume. If it builds inside the container as root it's a pain to deal with the root owned build artifacts afterwards.

@JonasVautherin
Copy link

I see.

Anyway, they can still try to mount it on /home/Firmware instead of /home/user/.... That helped in my case.

@dagar
Copy link
Member

dagar commented Sep 25, 2017

@Stifael can you share the full output for how you're running this and what you see?

@dagar dagar self-assigned this Sep 25, 2017
@dagar dagar added the bug label Sep 25, 2017
@Stifael
Copy link

Stifael commented Sep 25, 2017

my current issue is completely different to what I had before. This is the small script that I used:

#! /bin/bash

docker run -it --privileged \
-v ~/src/Firmware:/home/docker1000/src/firmware/:rw \
-v /tmp/.X11-unix:/tmp/.X11-unix:ro \
-e DISPLAY=:0 \
-p 14556:14556/udp \
--env=LOCAL_USER_ID="$(id -u)" \
--name=docker_px4_dev_ros px4io/px4-dev-ros  bash

When I go into /home/docker1000/src/firmware, and then want to build make posix_sitl_default,
I receive error

[96/531] Generating git hash header
FAILED: cd /home/docker1000/src/firmware && /home/docker1000/src/firmware/Tools/px_update_git_header.py /home/docker1000/src/firmware/build_posix_sitl_default/build_git_version.h > /home/docker1000/src/firmware/build_posix_sitl_default/git_header.log
Traceback (most recent call last):
  File "/home/docker1000/src/firmware/Tools/px_update_git_header.py", line 17, in <module>
    stderr=subprocess.STDOUT).decode('utf-8').strip()
  File "/usr/lib/python2.7/subprocess.py", line 574, in check_output
    raise CalledProcessError(retcode, cmd, output=output)
subprocess.CalledProcessError: Command '['git', 'describe', '--always', '--tags', '--dirty']' returned non-zero exit status 128

@JonasVautherin
Copy link

This seems more like git returning an error status 128 than a docker issue. Did you try to run the command multiple times?

@dagar
Copy link
Member

dagar commented Sep 25, 2017

It might be a path issue for git. Try keeping the same absolute path within the container.

You can use this crappy script in Firmware to launch docker with the appropriate container, user setup, volume in the right place, etc.

./Tools/docker_run.sh 'make posix_sitl_default'

./Tools/docker_run.sh 'bash'

@lamping7
Copy link
Member

lamping7 commented Dec 22, 2017

I just ran across this and figured I'd comment. I don't have these issues.

I'm using docker run -it -d --net=host -v /home/tony/Firmware:/home/root/Firmware --name px4-testing px4-test
Then docker exec -it px4-testing bash whenever I want to get in there: after this run command or in the future (after I start the container of course).

Additionally, not using the root account would be better. I didn't need LOCAL_USER_ID but it is probably the better way of doing this. I didn't setup for GUI apps, don't need them. The px4-test image I made was pulled from px4-dev-ros:latest earlier this month. I prefer to run it detached, in the background and get into it when I need to. Using net host allows me to not to have to worry about ports, which could be an issue for multiple UAVs -- it's also just easier and I don't care about isolation or running multiple containers.

The error above is from git describe --always --tags --dirty command probably due to a submodule issue. I've seen this happen when git couldn't identify a submodule as a repository (something like: fatal: Not a git repository: ../../.git/modules/Tools/jMAVSim. There are most probably other (more elegant) solutions, but to fix I simply removed the whole Firmware repo and cloned it again, then I could make posix_sitl_default as expected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants