Closed LoSunny closed 10 months ago
Hello,
thank you for you feedback. However, I'm not able to reproduce the issue. Can you provide more information abou your environment?
Are you on Windows or Linux? Does your container run locally or in the cloud? Which image have you used?
This is what I've got by using the image accetto/ubuntu-vnc-xfce-g3:latest, running it locally on Linux and connecting to it via noVNC:
Regards, accetto
Here is part of my docker-compose.yml
file
services:
ubuntu:
image: accetto/ubuntu-vnc-xfce-g3:latest
ports:
- 6901:6901
The container is deployed in okteto cloud
I'm afraid that okteto could be limiting root access. Have you checked their security policy?
I would also use different port binding. The local port 6901 could be already in use or blocked.
Try something like 36901:6901
.
okteto allow us to bind to any http port, so it shouldn't be a problem.
But what do you mean by security policy
?
This? https://www.okteto.com/docs/cloud/multitenancy/
I mean that cloud providers often limit usage of elevated permissions, so it could be the case here.
What do you see as the actual user in your container? What is the output of the command id
?
Have you tried to set the root as the explicit container user? Like docker run --user 0 ...
$ id
uid=1001(headless) gid=0(root) groups=0(root),27(sudo)
When I change the user to USER 0
through a Dockerfile
, I'm able to execute root
commands like apt update
It's interesting, the id
output is correct.
You can always set the user to 0 (=root) in the Dockerfile, but some applications will refuse tu run under the root account.
Btw, does it also work if you set the user 0 in your compose file?
If you don't need apt
for general use, but only for installing some particular applications, then you can also extend the Dockerfile to instal them before switching to the non-root user 1001.
The problem seems to be somewhere outside the container. You can check also this issue, for example.
Btw, do you bind any external volumes to your container?
Btw, does it also work if you set the user 0 in your compose file?
Yep
Btw, do you bind any external volumes to your container?
No
Yes I can install all the packages before starting the container with Dockerfile
, but sometimes when I want to test a new software, I won't be able to install its dependency easily.
I'm afraid that the problem has something to do with the restricted capabilities described in the section Pod Security Policies.
If you would closer describe your use case and provide an example of the compose file you use, I could find some time to try to reproduce it on okteto. Unfortunately I cannot reproduce the problem in my environment.
There is the steps to re-produce the problem in okteto
https://github.com/LoSunny/ubuntu-vnc-xfce-g3-test
Endpoints: xxxxxx
Till now I can only confirm the behaviour. I'm trying to pinpoint the problem, but no success yet.
The error message sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?
seems to be misleading, because:
I've also found, that you cannot actually set the capabilities, even if there is an example like cap_add: - ALL
in the documentation. There is only one capability, which is not refused, but it also doesn't solve the problem.
It seems more and more like an Okteto's bug (?).
Have you tested it also on some other cloud, maybe?
If that's the case, then it might be an issue with okteto
cloud provider. As I cannot re-produce the issue on my MacBook Docker Desktop
I'm having similar issues. I use this image as a base and install other software on it in Docker, but I have to set USER 0
otherwise it asks for password. Everything works, but if I later run the image with docker-compose and set user to 1000 i get lots of permission issues:
/dockerstartup/vnc_startup.rc: line 52: /home/headless/.vnc/passwd: Permission denied
chmod: changing permissions of '/home/headless/.vnc/passwd': Operation not permitted
/dockerstartup/vnc_startup.rc: line 60: /home/headless/.vnc/config: Permission denied
/dockerstartup/vnc_startup.rc: line 74: /dockerstartup/vnc.log: Permission denied
/dockerstartup/vnc_startup.rc: line 83: /dockerstartup/vnc.log: Permission denied
I also tried to build the image myself by enabling the user override?
FEATURES_USER_GROUP_OVERRIDE=1 DOCKER_BUILDKIT=1 ./docker/hooks/build main latest
But this doesn't help, or I don't understand clearly how I should do it
Hello @marisancans ,
sorry for the late answer, but I've noticed your question only a few days ago.
I've tried to reproduce the problems, but by me everything worked OK.
Maybe you've bound the dockerstartup/
folder as an external volume, haven't you?
If not, then try to set the permissions by adding the following to your Dockerfile
:
RUN "${STARTUPDIR}"/set_user_permissions.sh "${HOME}"
It'll help, if you provide more information about your environment and what packages you try to add.
Anyhow, I've added two new files Dockerfile.extend and example.yml that show how to use the images as the base for new images and how to switch users in compose file. Both files worked fine in my environment.
Regards, accetto
@accetto First of all, thank you for creating this docker image! A friend of mine introduced me to your project as a lighter weight kasm alternative that wasn't constrained to the web browser, which is great because I'm running out of hard drive space from all the images I've pulled or built locally and I really miss my keybindings that are otherwise inaccessible via kasm :smiling_face_with_tear:
I ran into a similar issue as @marisancans and tried your suggested fix of adding the RUN "${STARTUPDIR}"/set_user_permissions.sh "${HOME}"
line in my Dockerfile. However, I'm encountering the build error /bin/sh: 1: /dockerstartup/set_user_permission.sh: not found
. I ran the base image locally to check that the /dockerstartup/set_user_permission.sh
file path exists and it seems to be there. Any idea as to what might be the issue?
Here's the build error on my CI https://github.com/capsulecorplab/ltc-workspace-image/actions/runs/3606819773/jobs/6078430721#step:5:1752
@capsulecorplab Thank you for your feedback.
I see the following two lines in the log:
ERROR: failed to solve: executor failed running [/bin/sh -c $STARTUPDIR/set_user_permission.sh $HOME]: exit code: 127
Error: buildx failed with: ERROR: failed to solve: executor failed running [/bin/sh -c $STARTUPDIR/set_user_permission.sh $HOME]: exit code: 127
I think, that you need to assure using the bash
shell, not sh
. For example, this is what I have in my GitLab script:
variable:
SHELL: "/bin/bash"
However, additionally to that I had to extend the docker
executor image by installing the "proper" GNU bash
version, because the image itself is based on alpine
:
Actually, this is the complete Dockerfile
I currently use for my executor image:
# docker build -f Dockerfile.docker -t g3/docker:20.10.21 .
### This is the docker-in-docker executor image.
### The additional packages are required only by the G3 projects.
FROM docker:20.10.21
RUN apk --no-cache add \
bash \
curl \
git \
grep \
sed \
wget
You have also to ensure, that all script files are executable. This is what I do in my GitLab script after cloning the repository:
### make all script files executable
- find . -name "*.sh" -exec chmod +x '{}' \;
- chmod +x docker/${BUILDER_PROJECT}/hooks/*
Please let me know if it helped. Otherwise we'll investigate it further.
Regards, accetto
@accetto How would I go about setting the shell path for a local build? I get the same build error when I attempt to build the image locally with docker-compose build
.
Usually it's set as an environment variable SHELL=/bin/bash
. Check waht you have on your machine:
echo $SHELL
which bash
### my output
/usr/bin/bash
bash -version
### my output
GNU bash, version 5.1.4(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Please try to use the provided builder.sh
script. Please be sure to exucute it from the project's root directory:
./builder.sh latest all-no-push
Does it work? What is in the scrap_builder.log
?
Seems to be set correctly
$ echo $SHELL
/bin/bash
$ /bin/bash -version
GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
captainpike@captainpike-ThinkPad-T490:~/repo/iiac-workspac
$ ./builder.sh latest all-no-push
==> EXECUTING @2022-12-03_11-05-45: ./builder.sh
==> EXECUTING @2022-12-03_11-05-45: ./docker/hooks/pre_build dev latest
==> EXECUTING @2022-12-03_11-05-45: ./docker/hooks/cache dev latest
==> G3-CACHE hit file 'tigervnc-1.12.0.x86_64.tar.gz' in section 'tigervnc'
==> G3-CACHE hit file 'v1.3.0.tar.gz' in section 'novnc'
==> G3-CACHE hit file 'v0.10.0.tar.gz' in section 'websockify'
==> FINISHED @2022-12-03_11-05-45: ./docker/hooks/cache
Removing helper files
+ docker build -f ./docker/Dockerfile.xfce --build-arg BUILDKIT_INLINE_CACHE=1 --build-arg BASEIMAGE=ubuntu --build-arg BASETAG=20.04 --build-arg ARG_APT_NO_RECOMMENDS=1 --build-arg ARG_TIGERVNC_DISTRO=x86_64 --build-arg ARG_TIGERVNC_VERSION=1.12.0 --build-arg ARG_NOVNC_VERSION=1.3.0 --build-arg ARG_WEBSOCKIFY_VERSION=0.10.0 --build-arg ARG_MERGE_STAGE_VNC_BASE=stage_novnc -t accetto/:latest_helper ./docker
invalid argument "accetto/:latest_helper" for "-t, --tag" flag: invalid reference format
See 'docker build --help'.
$ cat scrap_builder.log
==> EXECUTING @2022-12-03_11-05-45: ./builder.sh
==> EXECUTING @2022-12-03_11-05-45: ./docker/hooks/pre_build dev latest
==> EXECUTING @2022-12-03_11-05-45: ./docker/hooks/cache dev latest
==> G3-CACHE hit file 'tigervnc-1.12.0.x86_64.tar.gz' in section 'tigervnc'
==> G3-CACHE hit file 'v1.3.0.tar.gz' in section 'novnc'
==> G3-CACHE hit file 'v0.10.0.tar.gz' in section 'websockify'
==> FINISHED @2022-12-03_11-05-45: ./docker/hooks/cache
Removing helper files
+ docker build -f ./docker/Dockerfile.xfce --build-arg BUILDKIT_INLINE_CACHE=1 --build-arg BASEIMAGE=ubuntu --build-arg BASETAG=20.04 --build-arg ARG_APT_NO_RECOMMENDS=1 --build-arg ARG_TIGERVNC_DISTRO=x86_64 --build-arg ARG_TIGERVNC_VERSION=1.12.0 --build-arg ARG_NOVNC_VERSION=1.3.0 --build-arg ARG_WEBSOCKIFY_VERSION=0.10.0 --build-arg ARG_MERGE_STAGE_VNC_BASE=stage_novnc -t accetto/:latest_helper ./docker
invalid argument "accetto/:latest_helper" for "-t, --tag" flag: invalid reference format
See 'docker build --help'.
Oh, I see. The BUILDER_REPO
environment variable is not set. It defines the name of your image on the local stage. See the part invalid argument "accetto/:latest_helper"
.
Please be sure that you've edited and sourced the secrets.rc
file before building the images. The file can be named differently or you can set all necessary variables also manually. Check the file readme-util-readme-examples.md
.
My repo probably isn't properly configured to run the builder scripts at the moment; I've mostly just been building images with the docker-compose.yml and Dockerfile using the docker-compose build
command. It's worth noting the image builds just fine with this approach if I comment out the lines that are setting and calling /dockerstartup
in the Dockerfile
, but then I run into the permission issue when trying to start up the image with docker-compose up
.
The following two changes could help with the permission problem. However, you have to test it in your environment, because by me everything works fine.
Scenario 1
Try to change the following line in the Dockerfile:
### from
&& chmod 755 -R "${STARTUPDIR}" \
### to
&& chmod 777 -R "${STARTUPDIR}" \
Scenario 2
Disable the following lines in the Dockerfile
and do those settings in your compose file.
USER 1001
ENTRYPOINT [ "/usr/bin/tini", "--", "/dockerstartup/startup.sh" ]
Scenario 3
You can optionally test it also with the alternative entry point line in the `Dockerfile. The VNC server will not be started, but you'll find out, if there is a problem with the startup script itself or its permissions.
ENTRYPOINT [ "/usr/bin/tini", "--", "tail", "-f", "/dev/null" ]
When I start the container, login to noVNC, try to open a terminal and run
sudo apt update
, it will return an errorWhen I run
su root
, and enter the default passwordheadless
, it will printAccording to the docs, I should be able to enter
sudo
, but I can't. Is there something wrong?