Docker Desktop in Linux documentation

[GallopingTurtle]

Describe the bug

For many operations, including generating a plugin, I get a filesystem permission denied error.

To Reproduce

If not installed, install docker as directed in the docs. Else, terminate and delete all images and volumes.

cd ~/
git clone https://github.com/OpenC3/cosmos-project.git
cd cosmos-project
PATH="~/cosmos-project:$PATH"
# OPTIONAL. Reqd to see error in browser
openc3.sh start
# ERROR!
openc3.sh cli generate plugin demotest

after running the generate, I see

WARNING: daemon is not using the default seccomp profile
/usr/lib/ruby/3.2.0/fileutils.rb:406:in `mkdir': Permission denied @ dir_s_mkdir - openc3-cosmos-demotest (Errno::EACCES)
    from /usr/lib/ruby/3.2.0/fileutils.rb:406:in `fu_mkdir'
    from /usr/lib/ruby/3.2.0/fileutils.rb:326:in `block in mkdir'
    from /usr/lib/ruby/3.2.0/fileutils.rb:325:in `each'
    from /usr/lib/ruby/3.2.0/fileutils.rb:325:in `mkdir'
    from /usr/lib/ruby/gems/3.2.0/gems/openc3-5.17.1/lib/openc3/utilities/cli_generator.rb:85:in `generate_plugin'
    from /usr/lib/ruby/gems/3.2.0/gems/openc3-5.17.1/lib/openc3/utilities/cli_generator.rb:30:in `generate'
    from /openc3/bin/openc3cli:688:in `<main>'

Possible Solution?

openc3.sh cliroot generate plugin demotest works as intended.

Browser Impact

On the fresh install we just made, navigate to http://localhost:2900, set a password the telemetry viewer > new page (there should have already been an unhelpful error toast) > Target=INST2 > New Screen Packet=[BLANK] > screen name=helpme

Response

Response value was {"status":"error","message":"Permission denied @ dir_s_mkdir - /plugins/DEFAULT/targets_modified"} from the http://localhost:2900/openc3-api/screen/?scope=DEFAULT endpoint.

Expected behavior No errors, be able to complete the examples

Environment (please complete the following information):

OS: Ubuntu 22.04.4 LTS x86_64 
Host: Latitude 5540 
Kernel: 6.5.0-41-generic 
Uptime: 13 mins 
Packages: 1676 (dpkg), 11 (flatpak), 13 (snap) 
Shell: bash 5.1.16 
Resolution: 3440x1440 
DE: GNOME 42.9 
WM: Mutter 
WM Theme: Adwaita 
Theme: Yaru-olive-dark [GTK2/3] 
Icons: Yaru-olive [GTK2/3] 
Terminal: gnome-terminal 
CPU: 13th Gen Intel i7-1365U (12) @ 5.200GHz 
GPU: Intel Device a7a1 
Memory: 7433MiB / 15639MiB 

Docker version 27.0.3, build 7d4bcd8 Docker Compose version v2.28.1-desktop.1 Docker Desktop Version: 4.32.0

[ryanmelt]

What is your umask? umask

If its not 022 before you did the git clone, that might be your problem.

[GallopingTurtle]

umask was 0002, changed it to 0022 and retried, got the same error

[ryanmelt]

Permissions are always fun. The openc3.sh script tries to run containers as the same user that is on the host and that generally works around most issues with doing host volume mounts.

If you look into openc3.sh, this is the line that runs the generators: docker run -it --rm --env-file "$(dirname -- "$0")/.env" --user=$OPENC3_USER_ID:$OPENC3_GROUP_ID --network openc3-cosmos-network -v `pwd`:/openc3/local:z -w /openc3/local $OPENC3_REGISTRY/$OPENC3_NAMESPACE/openc3-operator$OPENC3_IMAGE_SUFFIX:$OPENC3_TAG ruby /openc3/bin/openc3cli $args

Its a bit complicated, but the important parts are: --user=$OPENC3_USER_ID:$OPENC3_GROUP_ID

OPENC3_USER_ID is set earlier in the script doing:

docker info | grep -e "rootless$" -e "rootless: true"
if [ "$?" -ne 0 ]; then
  export OPENC3_ROOTFUL=1
  export OPENC3_USER_ID=`id -u`
  export OPENC3_GROUP_ID=`id -g`
else
  export OPENC3_ROOTLESS=1
  export OPENC3_USER_ID=0
  export OPENC3_GROUP_ID=0
fi

For a normal docker setup (not rootless) that will be the userid returned by id -u

Then we volume mount in the current folder: -v `pwd`:/openc3/local:z

And that is where the generators try to write files and are currently getting a permissions error.

If you have a support contract, I'd be happy to jump on a call and help debug. Otherwise, hopefully this points you in the right direction. The container must be running as a user that has permissions to write to your host filesystem via the volume mount.

[GallopingTurtle]

Changing the umask to 0000 worked, but I'm not sure that should be the solution.

I hijacked that run command (which is rootful based on my install and uses my uid and gid) and ran ls -ltr.

For some reason root is the owner of /openc3/local. openc3 is the owner of /openc3 but root also owns (in /openc3) .bundle, Gemfile.lock, gems, local. From my research, this is the source of my issue. I can take ownership of local, but not the other items and my issue still persists.

[ryanmelt]

I'll spin up an ubuntu VM and see if I can reproduce. How was docker installed (system package or script from docker.io)? Feels like some sort of Docker security setting.

[ryanmelt]

Ah, just noticed you are using the linux Docker Desktop version of docker. I've never tried that and it is most likely the problem. We recommend installing docker directly on linux machines and not using Docker Desktop.

[GallopingTurtle]

Installed from the docs here: https://docs.docker.com/desktop/install/ubuntu/#install-docker-desktop (downloaded the deb) as referenced from here: https://docs.openc3.com/docs/getting-started/installation#prerequisites

[ryanmelt]

This is what is causing the issue: https://docs.docker.com/desktop/faqs/linuxfaqs/#how-do-i-enable-file-sharing

From reading that it sounds like we'll want to treat docker desktop on linux, like using a rootless setup. Let me try it out and see if we can autodetect that configuration.

In the near term, you can modify your openc3.sh to force it to detect a rootless setup and run the containers as "root". It will just be root inside the docker desktop VM, not on the host for that case, and the user should map back to your host user account and I think it work.

[GallopingTurtle]

Can confirm forcing the else branch of the mentioned if solved this issue in full