Hello there, I have bind-mounted a local dir inside a container. Once the container is closed the directory permissions are changed to a subuid and I have to run `podman unshare chown -R 0:0 /path/to/dir` manually if I want to do anything with the bind-mounted directory. I was wondering if there is a method whereby a container (or a pod) could be configured to do this automatically? I'd be glad to know about it (or any other ways to get around this minor issue). Thank you.
I wrote two troubleshooting tips that describes how --uidmap and --gidmap can be used to handle situations like that: https://github.com/containers/podman/blob/main/troubleshooting.md#34-passed-... https://github.com/containers/podman/blob/main/troubleshooting.md#33-contain... Another alternative is to use the volume option ":U". Quote "The :U suffix tells Podman to use the correct host UID and GID based on the UID and GID within the container, to change recursively the owner and group of the source volume." from https://docs.podman.io/en/latest/markdown/podman-run.1.html#volume-v-source-... If you can use --uidmap and --gidmap (or --userns=keep-id), you probably don't need to run chown or use ":U". Regards, Erik Sjölund On Tue, Feb 15, 2022 at 10:15 PM Prafulla Giri via Podman <podman@lists.podman.io> wrote:
Hello there,
I have bind-mounted a local dir inside a container. Once the container is closed the directory permissions are changed to a subuid and I have to run `podman unshare chown -R 0:0 /path/to/dir` manually if I want to do anything with the bind-mounted directory. I was wondering if there is a method whereby a container (or a pod) could be configured to do this automatically? I'd be glad to know about it (or any other ways to get around this minor issue).
Thank you. _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
Hello there, Thank you for the pointers. I tried using :U (with Z - :U,Z) and that didn't do the trick. I also tried using --userns=keep-id, and that also didn't work. I tried following https://github.com/containers/podman/blob/main/troubleshooting.md#33-contain... and I must admit, while the sample works, I don't understand it enough to translate it to my use case (and it is quite unwieldy). I have a really hard time wrapping my head around what is going on with --uidmap 2003:0:1 (set the user inside the container to map to uid 0 (root?) on the host ?) and another --uidmap 2004:2004:65536 (set the user 20004 onwards to map to uid 2004 on the host)? This is the exact container/volume that I'm having trouble with: $ mkdir gogs $ podman run -v ./gogs:/data docker.io/gogs/gogs The user `git` inside the container has uid 1000, and is mapped to uid 100999 outside the container. In the end, ./gogs is owned by 100999. ------- Original Message ------- On Wednesday, February 16th, 2022 at 4:19 PM, Erik Sjölund <erik.sjolund@gmail.com> wrote:
I wrote two troubleshooting tips that describes how --uidmap and
--gidmap can be used to handle situations like that:
https://github.com/containers/podman/blob/main/troubleshooting.md#34-passed-...
https://github.com/containers/podman/blob/main/troubleshooting.md#33-contain...
Another alternative is to use the volume option ":U".
Quote
"The :U suffix tells Podman to use the correct host UID and GID based
on the UID and GID within the container, to change recursively the
owner and group of the source volume."
from
https://docs.podman.io/en/latest/markdown/podman-run.1.html#volume-v-source-...
If you can use --uidmap and --gidmap (or --userns=keep-id), you
probably don't need to run chown or use ":U".
Regards,
Erik Sjölund
On Tue, Feb 15, 2022 at 10:15 PM Prafulla Giri via Podman
podman@lists.podman.io wrote:
Hello there,
I have bind-mounted a local dir inside a container. Once the container is closed the directory permissions are
changed to a subuid and I have to run `podman unshare chown -R 0:0 /path/to/dir` manually if I want to do anything
with the bind-mounted directory. I was wondering if there is a method whereby a container (or a pod) could be configured
to do this automatically? I'd be glad to know about it (or any other ways to get around this minor issue).
Thank you.
Podman mailing list -- podman@lists.podman.io
To unsubscribe send an email to podman-leave@lists.podman.io
Podman mailing list -- podman@lists.podman.io
To unsubscribe send an email to podman-leave@lists.podman.io
I tried to run this Bash script #!/bin/bash uid=1000 gid=1000 subuidSize=$(( $(podman info --format "{{ range .Host.IDMappings.UIDMap }}+{{.Size }}{{end }}" ) - 1 )) subgidSize=$(( $(podman info --format "{{ range .Host.IDMappings.GIDMap }}+{{.Size }}{{end }}" ) - 1 )) podman run --rm \ -v ./gogs:/data:Z \ --uidmap $uid:0:1 \ --uidmap 0:1:$uid \ --uidmap $(($uid+1)):$(($uid+1)):$(($subuidSize-$uid)) \ --gidmap $gid:0:1 \ --gidmap 0:1:$gid \ --gidmap $(($gid+1)):$(($gid+1)):$(($subgidSize-$gid)) \ --name=gogs -p 10022:22 -p 10880:3000 \ docker.io/gogs/gogs [tester@laptop ~]$ podman --version podman version 3.4.4 [tester@laptop ~]$ bash run.sh usermod: no changes Feb 18 19:14:58 syslogd started: BusyBox v1.33.1 2022/02/18 19:14:58 [ WARN] Custom config "/data/gogs/conf/app.ini" not found. Ignore this warning if you're running for the first time 2022/02/18 19:14:58 [TRACE] Log mode: Console (Trace) 2022/02/18 19:14:58 [ INFO] Gogs 0.13.0+dev 2022/02/18 19:14:58 [TRACE] Work directory: /app/gogs 2022/02/18 19:14:58 [TRACE] Custom path: /data/gogs 2022/02/18 19:14:58 [TRACE] Custom config: /data/gogs/conf/app.ini 2022/02/18 19:14:58 [TRACE] Log path: /app/gogs/log 2022/02/18 19:14:58 [TRACE] Build time: 2022-02-14 02:18:07 UTC 2022/02/18 19:14:58 [TRACE] Build commit: 8a1a40ce6a2fcad2ca877c1c98dcf492c5f9fbed 2022/02/18 19:14:58 [ INFO] Run mode: Development Feb 18 19:14:58 sshd[45]: Server listening on :: port 22. Feb 18 19:14:58 sshd[45]: Server listening on 0.0.0.0 port 22. 2022/02/18 19:14:58 [ INFO] Listen on http://0.0.0.0:3000 I didn't try connecting with a web browser but at least the file permissions look OK. In another shell: [tester@fcos ~]$ ls -l gogs total 4 drwxr-xr-x. 3 tester tester 18 Feb 18 19:14 git drwxr-xr-x. 5 tester tester 41 Feb 18 19:14 gogs drwx------. 2 tester tester 4096 Feb 18 19:14 ssh [tester@fcpos ~]$ I haven't figured out yet why adding --user $uid:$gid fails though. Kind regards, Erik Sjölund On Fri, Feb 18, 2022 at 7:54 PM Prafulla Giri <prafulla.giri@protonmail.com> wrote:
Hello there,
Thank you for the pointers.
I tried using :U (with Z - :U,Z) and that didn't do the trick.
I also tried using --userns=keep-id, and that also didn't work.
I tried following https://github.com/containers/podman/blob/main/troubleshooting.md#33-contain... and I must admit, while the sample works, I don't understand it enough to translate it to my use case (and it is quite unwieldy). I have a really hard time wrapping my head around what is going on with --uidmap 2003:0:1 (set the user inside the container to map to uid 0 (root?) on the host ?) and another --uidmap 2004:2004:65536 (set the user 20004 onwards to map to uid 2004 on the host)?
This is the exact container/volume that I'm having trouble with: $ mkdir gogs $ podman run -v ./gogs:/data docker.io/gogs/gogs
The user `git` inside the container has uid 1000, and is mapped to uid 100999 outside the container. In the end, ./gogs is owned by 100999.
------- Original Message -------
On Wednesday, February 16th, 2022 at 4:19 PM, Erik Sjölund <erik.sjolund@gmail.com> wrote:
I wrote two troubleshooting tips that describes how --uidmap and
--gidmap can be used to handle situations like that:
https://github.com/containers/podman/blob/main/troubleshooting.md#34-passed-...
https://github.com/containers/podman/blob/main/troubleshooting.md#33-contain...
Another alternative is to use the volume option ":U".
Quote
"The :U suffix tells Podman to use the correct host UID and GID based
on the UID and GID within the container, to change recursively the
owner and group of the source volume."
from
https://docs.podman.io/en/latest/markdown/podman-run.1.html#volume-v-source-...
If you can use --uidmap and --gidmap (or --userns=keep-id), you
probably don't need to run chown or use ":U".
Regards,
Erik Sjölund
On Tue, Feb 15, 2022 at 10:15 PM Prafulla Giri via Podman
podman@lists.podman.io wrote:
Hello there,
I have bind-mounted a local dir inside a container. Once the container is closed the directory permissions are
changed to a subuid and I have to run `podman unshare chown -R 0:0 /path/to/dir` manually if I want to do anything
with the bind-mounted directory. I was wondering if there is a method whereby a container (or a pod) could be configured
to do this automatically? I'd be glad to know about it (or any other ways to get around this minor issue).
Thank you.
Podman mailing list -- podman@lists.podman.io
To unsubscribe send an email to podman-leave@lists.podman.io
Podman mailing list -- podman@lists.podman.io
To unsubscribe send an email to podman-leave@lists.podman.io
Prafulla, I did some more testing. It looks to be working. w3m was able to browse the web page: [tester@laptop ~]$ w3m http://localhost:10880 An ssh client was able to connect to the ssh server. [tester@laptop ~]$ ssh -p 10022 localhost The authenticity of host '[localhost]:10022 ([::1]:10022)' can't be established. ED25519 key fingerprint is SHA256:rRXoPCat1mA7cGWCr9TOUxGYzQafFUEr2yXKIH+Oe8w. This key is not known by any other names Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '[localhost]:10022' (ED25519) to the list of known hosts. tester@localhost: Permission denied (publickey,keyboard-interactive). [tester@laptop ~]$ Maybe you could try the Bash script run.sh and see if it works for you? Kind regards Erik Sjölund On Fri, Feb 18, 2022 at 8:49 PM Erik Sjölund <erik.sjolund@gmail.com> wrote:
I tried to run this Bash script
#!/bin/bash uid=1000 gid=1000 subuidSize=$(( $(podman info --format "{{ range .Host.IDMappings.UIDMap }}+{{.Size }}{{end }}" ) - 1 )) subgidSize=$(( $(podman info --format "{{ range .Host.IDMappings.GIDMap }}+{{.Size }}{{end }}" ) - 1 )) podman run --rm \ -v ./gogs:/data:Z \ --uidmap $uid:0:1 \ --uidmap 0:1:$uid \ --uidmap $(($uid+1)):$(($uid+1)):$(($subuidSize-$uid)) \ --gidmap $gid:0:1 \ --gidmap 0:1:$gid \ --gidmap $(($gid+1)):$(($gid+1)):$(($subgidSize-$gid)) \ --name=gogs -p 10022:22 -p 10880:3000 \ docker.io/gogs/gogs
[tester@laptop ~]$ podman --version podman version 3.4.4 [tester@laptop ~]$ bash run.sh usermod: no changes Feb 18 19:14:58 syslogd started: BusyBox v1.33.1 2022/02/18 19:14:58 [ WARN] Custom config "/data/gogs/conf/app.ini" not found. Ignore this warning if you're running for the first time 2022/02/18 19:14:58 [TRACE] Log mode: Console (Trace) 2022/02/18 19:14:58 [ INFO] Gogs 0.13.0+dev 2022/02/18 19:14:58 [TRACE] Work directory: /app/gogs 2022/02/18 19:14:58 [TRACE] Custom path: /data/gogs 2022/02/18 19:14:58 [TRACE] Custom config: /data/gogs/conf/app.ini 2022/02/18 19:14:58 [TRACE] Log path: /app/gogs/log 2022/02/18 19:14:58 [TRACE] Build time: 2022-02-14 02:18:07 UTC 2022/02/18 19:14:58 [TRACE] Build commit: 8a1a40ce6a2fcad2ca877c1c98dcf492c5f9fbed 2022/02/18 19:14:58 [ INFO] Run mode: Development Feb 18 19:14:58 sshd[45]: Server listening on :: port 22. Feb 18 19:14:58 sshd[45]: Server listening on 0.0.0.0 port 22. 2022/02/18 19:14:58 [ INFO] Listen on http://0.0.0.0:3000
I didn't try connecting with a web browser but at least the file permissions look OK. In another shell:
[tester@fcos ~]$ ls -l gogs total 4 drwxr-xr-x. 3 tester tester 18 Feb 18 19:14 git drwxr-xr-x. 5 tester tester 41 Feb 18 19:14 gogs drwx------. 2 tester tester 4096 Feb 18 19:14 ssh [tester@fcpos ~]$
I haven't figured out yet why adding --user $uid:$gid fails though.
Kind regards, Erik Sjölund
On Fri, Feb 18, 2022 at 7:54 PM Prafulla Giri <prafulla.giri@protonmail.com> wrote:
Hello there,
Thank you for the pointers.
I tried using :U (with Z - :U,Z) and that didn't do the trick.
I also tried using --userns=keep-id, and that also didn't work.
I tried following https://github.com/containers/podman/blob/main/troubleshooting.md#33-contain... and I must admit, while the sample works, I don't understand it enough to translate it to my use case (and it is quite unwieldy). I have a really hard time wrapping my head around what is going on with --uidmap 2003:0:1 (set the user inside the container to map to uid 0 (root?) on the host ?) and another --uidmap 2004:2004:65536 (set the user 20004 onwards to map to uid 2004 on the host)?
This is the exact container/volume that I'm having trouble with: $ mkdir gogs $ podman run -v ./gogs:/data docker.io/gogs/gogs
The user `git` inside the container has uid 1000, and is mapped to uid 100999 outside the container. In the end, ./gogs is owned by 100999.
------- Original Message -------
On Wednesday, February 16th, 2022 at 4:19 PM, Erik Sjölund <erik.sjolund@gmail.com> wrote:
I wrote two troubleshooting tips that describes how --uidmap and
--gidmap can be used to handle situations like that:
https://github.com/containers/podman/blob/main/troubleshooting.md#34-passed-...
https://github.com/containers/podman/blob/main/troubleshooting.md#33-contain...
Another alternative is to use the volume option ":U".
Quote
"The :U suffix tells Podman to use the correct host UID and GID based
on the UID and GID within the container, to change recursively the
owner and group of the source volume."
from
https://docs.podman.io/en/latest/markdown/podman-run.1.html#volume-v-source-...
If you can use --uidmap and --gidmap (or --userns=keep-id), you
probably don't need to run chown or use ":U".
Regards,
Erik Sjölund
On Tue, Feb 15, 2022 at 10:15 PM Prafulla Giri via Podman
podman@lists.podman.io wrote:
Hello there,
I have bind-mounted a local dir inside a container. Once the container is closed the directory permissions are
changed to a subuid and I have to run `podman unshare chown -R 0:0 /path/to/dir` manually if I want to do anything
with the bind-mounted directory. I was wondering if there is a method whereby a container (or a pod) could be configured
to do this automatically? I'd be glad to know about it (or any other ways to get around this minor issue).
Thank you.
Podman mailing list -- podman@lists.podman.io
To unsubscribe send an email to podman-leave@lists.podman.io
Podman mailing list -- podman@lists.podman.io
To unsubscribe send an email to podman-leave@lists.podman.io
I tried running the shell script you provided, and it does work. Could you please explain to me what the `--uidmap`s are doing, please? Why is the user 1000 inside the host mapped to the user 0 (root) on the host (--uidmap $uid:0:1)? Why is the root user inside the container mapped to uid 1 on the host (--uidmap 0:1:$uid)? The last one [--uidmap $(($uid+1)):$(($uid+1)):$(($subuidSize-$uid))] seems to be mapping all the rest of the users beyond 1000 to 1000+ on the host, for the entire subuid range. That one makes a bit of sense. (But even then, if I have another user `1001` on the host, that is mapping `1001` inside the container to that user?) Clearly, there are a lot of gaping holes in my understanding of namespaces. I would really appreciate it if you would point me to the right direction. Secondly, is there any reason why `:U` option isn't working for me? Is it working for you? If it is not doing what it is supposed to do, should I file a bug report? Likewise with `--userns=keep-id`. Thank you for your time and patience. ------- Original Message ------- On Saturday, February 19th, 2022 at 2:28 AM, Erik Sjölund <erik.sjolund@gmail.com> wrote:
Prafulla, I did some more testing.
It looks to be working.
w3m was able to browse the web page:
[tester@laptop ~]$ w3m http://localhost:10880
An ssh client was able to connect to the ssh server.
[tester@laptop ~]$ ssh -p 10022 localhost
The authenticity of host '[localhost]:10022 ([::1]:10022)' can't be established.
ED25519 key fingerprint is SHA256:rRXoPCat1mA7cGWCr9TOUxGYzQafFUEr2yXKIH+Oe8w.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[localhost]:10022' (ED25519) to the list
of known hosts.
tester@localhost: Permission denied (publickey,keyboard-interactive).
[tester@laptop ~]$
Maybe you could try the Bash script run.sh and see if it works for you?
Kind regards
Erik Sjölund
On Fri, Feb 18, 2022 at 8:49 PM Erik Sjölund erik.sjolund@gmail.com wrote:
I tried to run this Bash script
#!/bin/bash
uid=1000
gid=1000
subuidSize=$(( $(podman info --format "{{ range
.Host.IDMappings.UIDMap }}+{{.Size }}{{end }}" ) - 1 ))
subgidSize=$(( $(podman info --format "{{ range
.Host.IDMappings.GIDMap }}+{{.Size }}{{end }}" ) - 1 ))
podman run --rm \
-v ./gogs:/data:Z \
--uidmap $uid:0:1 \
--uidmap 0:1:$uid \
--uidmap $(($uid+1)):$(($uid+1)):$(($subuidSize-$uid)) \
--gidmap $gid:0:1 \
--gidmap 0:1:$gid \
--gidmap $(($gid+1)):$(($gid+1)):$(($subgidSize-$gid)) \
--name=gogs -p 10022:22 -p 10880:3000 \
docker.io/gogs/gogs
[tester@laptop ~]$ podman --version
podman version 3.4.4
[tester@laptop ~]$ bash run.sh
usermod: no changes
Feb 18 19:14:58 syslogd started: BusyBox v1.33.1
2022/02/18 19:14:58 [ WARN] Custom config "/data/gogs/conf/app.ini"
not found. Ignore this warning if you're running for the first time
2022/02/18 19:14:58 [TRACE] Log mode: Console (Trace)
2022/02/18 19:14:58 [ INFO] Gogs 0.13.0+dev
2022/02/18 19:14:58 [TRACE] Work directory: /app/gogs
2022/02/18 19:14:58 [TRACE] Custom path: /data/gogs
2022/02/18 19:14:58 [TRACE] Custom config: /data/gogs/conf/app.ini
2022/02/18 19:14:58 [TRACE] Log path: /app/gogs/log
2022/02/18 19:14:58 [TRACE] Build time: 2022-02-14 02:18:07 UTC
2022/02/18 19:14:58 [TRACE] Build commit:
8a1a40ce6a2fcad2ca877c1c98dcf492c5f9fbed
2022/02/18 19:14:58 [ INFO] Run mode: Development
Feb 18 19:14:58 sshd[45]: Server listening on :: port 22.
Feb 18 19:14:58 sshd[45]: Server listening on 0.0.0.0 port 22.
2022/02/18 19:14:58 [ INFO] Listen on http://0.0.0.0:3000
I didn't try connecting with a web browser but at least the file
permissions look OK.
In another shell:
[tester@fcos ~]$ ls -l gogs
total 4
drwxr-xr-x. 3 tester tester 18 Feb 18 19:14 git
drwxr-xr-x. 5 tester tester 41 Feb 18 19:14 gogs
drwx------. 2 tester tester 4096 Feb 18 19:14 ssh
[tester@fcpos ~]$
I haven't figured out yet why adding --user $uid:$gid fails though.
Kind regards,
Erik Sjölund
On Fri, Feb 18, 2022 at 7:54 PM Prafulla Giri
prafulla.giri@protonmail.com wrote:
Hello there,
Thank you for the pointers.
I tried using :U (with Z - :U,Z) and that didn't do the trick.
I also tried using --userns=keep-id, and that also didn't work.
I tried following https://github.com/containers/podman/blob/main/troubleshooting.md#33-contain... and I must admit, while the sample works, I don't understand it enough to translate it to my use case (and it is quite unwieldy). I have a really hard time wrapping my head around what is going on with --uidmap 2003:0:1 (set the user inside the container to map to uid 0 (root?) on the host ?) and another --uidmap 2004:2004:65536 (set the user 20004 onwards to map to uid 2004 on the host)?
This is the exact container/volume that I'm having trouble with:
$ mkdir gogs
$ podman run -v ./gogs:/data docker.io/gogs/gogs
The user `git` inside the container has uid 1000, and is mapped to uid 100999 outside the container. In the end, ./gogs is owned by 100999.
------- Original Message -------
On Wednesday, February 16th, 2022 at 4:19 PM, Erik Sjölund erik.sjolund@gmail.com wrote:
I wrote two troubleshooting tips that describes how --uidmap and
--gidmap can be used to handle situations like that:
https://github.com/containers/podman/blob/main/troubleshooting.md#34-passed-...
https://github.com/containers/podman/blob/main/troubleshooting.md#33-contain...
Another alternative is to use the volume option ":U".
Quote
"The :U suffix tells Podman to use the correct host UID and GID based
on the UID and GID within the container, to change recursively the
owner and group of the source volume."
from
https://docs.podman.io/en/latest/markdown/podman-run.1.html#volume-v-source-...
If you can use --uidmap and --gidmap (or --userns=keep-id), you
probably don't need to run chown or use ":U".
Regards,
Erik Sjölund
On Tue, Feb 15, 2022 at 10:15 PM Prafulla Giri via Podman
podman@lists.podman.io wrote:
Hello there,
I have bind-mounted a local dir inside a container. Once the container is closed the directory permissions are
changed to a subuid and I have to run `podman unshare chown -R 0:0 /path/to/dir` manually if I want to do anything
with the bind-mounted directory. I was wondering if there is a method whereby a container (or a pod) could be configured
to do this automatically? I'd be glad to know about it (or any other ways to get around this minor issue).
Thank you.
Podman mailing list -- podman@lists.podman.io
To unsubscribe send an email to podman-leave@lists.podman.io
Podman mailing list -- podman@lists.podman.io
To unsubscribe send an email to podman-leave@lists.podman.io
Why is the user 1000 inside the host mapped to the user 0 (root) on the host (--uidmap $uid:0:1)?
I assume you meant "Why is the user 1000 inside the container mapped to the user 0 (root) on the host (--uidmap $uid:0:1)?" The complicated part of using --uidmap together with rootless podman (i.e. running Podman from an unprivileged account), is that the mapping happens over two mappings steps. The first step is handled by Podman itself and can't be controlled by the user. The option --uidmap controls the second mapping step. So we have two steps: first mapping second mapping host UID --> intermediate UID --> container UID The name "intermediate UID" is just a name to be able to reason about the two mapping steps. The middle number in --uidmap is actually the intermediate UID when you are running rootless Podman. In other words --uidmap $uid:0:1 means: map the intermediate UID 0 to the container UID 1000. Why do we need to pass that option? The reason for this is that the first mapping step always maps the user's regular host UID to the intermediate UID 0. For instance if the user's regular UID on the host is 3456 and the container UID is $uid, the command-line argument --uidmap $uid:0:1 would map the host UID 3456 to the container UID $uid host UID (3456) -> intermediate UID (0) -> container UID ($uid) If you search for the text string "First mapping step" on the web page https://docs.podman.io/en/latest/markdown/podman-run.1.html#uidmap-container... you will find a table that describes how Podman handles the first mapping step.
Why is the root user inside the container mapped to uid 1 on the host (--uidmap 0:1:$uid)?
The digit 1 actually means intermediate UID 1. The first mapping step mapped the lowest subordinate UID to intermediate UID 1. Passing --uidmap 0:1:$uid translates to: host UID (first subordinate UID) -> intermediate UID (1) -> container UID 1 The last number in "--uidmap 0:1:$uid", $uid, specifies how many consecutive IDs should be mapped.
Secondly, is there any reason why `:U` option isn't working for me? Is it working for you? No, it didn't work for me. Sorry, I think ":U" is not so useful for the container image docker.io/gogs/gogs
should I file a bug report? I think everything is working as expected so there is no need for that.
On Sat, Feb 19, 2022 at 3:42 AM Prafulla Giri <prafulla.giri@protonmail.com> wrote:
I tried running the shell script you provided, and it does work.
Could you please explain to me what the `--uidmap`s are doing, please? Why is the user 1000 inside the host mapped to the user 0 (root) on the host (--uidmap $uid:0:1)? Why is the root user inside the container mapped to uid 1 on the host (--uidmap 0:1:$uid)? The last one [--uidmap $(($uid+1)):$(($uid+1)):$(($subuidSize-$uid))] seems to be mapping all the rest of the users beyond 1000 to 1000+ on the host, for the entire subuid range. That one makes a bit of sense. (But even then, if I have another user `1001` on the host, that is mapping `1001` inside the container to that user?)
Clearly, there are a lot of gaping holes in my understanding of namespaces. I would really appreciate it if you would point me to the right direction.
Secondly, is there any reason why `:U` option isn't working for me? Is it working for you? If it is not doing what it is supposed to do, should I file a bug report? Likewise with `--userns=keep-id`.
Thank you for your time and patience.
------- Original Message -------
On Saturday, February 19th, 2022 at 2:28 AM, Erik Sjölund <erik.sjolund@gmail.com> wrote:
Prafulla, I did some more testing.
It looks to be working.
w3m was able to browse the web page:
[tester@laptop ~]$ w3m http://localhost:10880
An ssh client was able to connect to the ssh server.
[tester@laptop ~]$ ssh -p 10022 localhost
The authenticity of host '[localhost]:10022 ([::1]:10022)' can't be established.
ED25519 key fingerprint is SHA256:rRXoPCat1mA7cGWCr9TOUxGYzQafFUEr2yXKIH+Oe8w.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[localhost]:10022' (ED25519) to the list
of known hosts.
tester@localhost: Permission denied (publickey,keyboard-interactive).
[tester@laptop ~]$
Maybe you could try the Bash script run.sh and see if it works for you?
Kind regards
Erik Sjölund
On Fri, Feb 18, 2022 at 8:49 PM Erik Sjölund erik.sjolund@gmail.com wrote:
I tried to run this Bash script
#!/bin/bash
uid=1000
gid=1000
subuidSize=$(( $(podman info --format "{{ range
.Host.IDMappings.UIDMap }}+{{.Size }}{{end }}" ) - 1 ))
subgidSize=$(( $(podman info --format "{{ range
.Host.IDMappings.GIDMap }}+{{.Size }}{{end }}" ) - 1 ))
podman run --rm \
-v ./gogs:/data:Z \
--uidmap $uid:0:1 \
--uidmap 0:1:$uid \
--uidmap $(($uid+1)):$(($uid+1)):$(($subuidSize-$uid)) \
--gidmap $gid:0:1 \
--gidmap 0:1:$gid \
--gidmap $(($gid+1)):$(($gid+1)):$(($subgidSize-$gid)) \
--name=gogs -p 10022:22 -p 10880:3000 \
docker.io/gogs/gogs
[tester@laptop ~]$ podman --version
podman version 3.4.4
[tester@laptop ~]$ bash run.sh
usermod: no changes
Feb 18 19:14:58 syslogd started: BusyBox v1.33.1
2022/02/18 19:14:58 [ WARN] Custom config "/data/gogs/conf/app.ini"
not found. Ignore this warning if you're running for the first time
2022/02/18 19:14:58 [TRACE] Log mode: Console (Trace)
2022/02/18 19:14:58 [ INFO] Gogs 0.13.0+dev
2022/02/18 19:14:58 [TRACE] Work directory: /app/gogs
2022/02/18 19:14:58 [TRACE] Custom path: /data/gogs
2022/02/18 19:14:58 [TRACE] Custom config: /data/gogs/conf/app.ini
2022/02/18 19:14:58 [TRACE] Log path: /app/gogs/log
2022/02/18 19:14:58 [TRACE] Build time: 2022-02-14 02:18:07 UTC
2022/02/18 19:14:58 [TRACE] Build commit:
8a1a40ce6a2fcad2ca877c1c98dcf492c5f9fbed
2022/02/18 19:14:58 [ INFO] Run mode: Development
Feb 18 19:14:58 sshd[45]: Server listening on :: port 22.
Feb 18 19:14:58 sshd[45]: Server listening on 0.0.0.0 port 22.
2022/02/18 19:14:58 [ INFO] Listen on http://0.0.0.0:3000
I didn't try connecting with a web browser but at least the file
permissions look OK.
In another shell:
[tester@fcos ~]$ ls -l gogs
total 4
drwxr-xr-x. 3 tester tester 18 Feb 18 19:14 git
drwxr-xr-x. 5 tester tester 41 Feb 18 19:14 gogs
drwx------. 2 tester tester 4096 Feb 18 19:14 ssh
[tester@fcpos ~]$
I haven't figured out yet why adding --user $uid:$gid fails though.
Kind regards,
Erik Sjölund
On Fri, Feb 18, 2022 at 7:54 PM Prafulla Giri
prafulla.giri@protonmail.com wrote:
Hello there,
Thank you for the pointers.
I tried using :U (with Z - :U,Z) and that didn't do the trick.
I also tried using --userns=keep-id, and that also didn't work.
I tried following https://github.com/containers/podman/blob/main/troubleshooting.md#33-contain... and I must admit, while the sample works, I don't understand it enough to translate it to my use case (and it is quite unwieldy). I have a really hard time wrapping my head around what is going on with --uidmap 2003:0:1 (set the user inside the container to map to uid 0 (root?) on the host ?) and another --uidmap 2004:2004:65536 (set the user 20004 onwards to map to uid 2004 on the host)?
This is the exact container/volume that I'm having trouble with:
$ mkdir gogs
$ podman run -v ./gogs:/data docker.io/gogs/gogs
The user `git` inside the container has uid 1000, and is mapped to uid 100999 outside the container. In the end, ./gogs is owned by 100999.
------- Original Message -------
On Wednesday, February 16th, 2022 at 4:19 PM, Erik Sjölund erik.sjolund@gmail.com wrote:
I wrote two troubleshooting tips that describes how --uidmap and
--gidmap can be used to handle situations like that:
https://github.com/containers/podman/blob/main/troubleshooting.md#34-passed-...
https://github.com/containers/podman/blob/main/troubleshooting.md#33-contain...
Another alternative is to use the volume option ":U".
Quote
"The :U suffix tells Podman to use the correct host UID and GID based
on the UID and GID within the container, to change recursively the
owner and group of the source volume."
from
https://docs.podman.io/en/latest/markdown/podman-run.1.html#volume-v-source-...
If you can use --uidmap and --gidmap (or --userns=keep-id), you
probably don't need to run chown or use ":U".
Regards,
Erik Sjölund
On Tue, Feb 15, 2022 at 10:15 PM Prafulla Giri via Podman
podman@lists.podman.io wrote:
Hello there,
I have bind-mounted a local dir inside a container. Once the container is closed the directory permissions are
changed to a subuid and I have to run `podman unshare chown -R 0:0 /path/to/dir` manually if I want to do anything
with the bind-mounted directory. I was wondering if there is a method whereby a container (or a pod) could be configured
to do this automatically? I'd be glad to know about it (or any other ways to get around this minor issue).
Thank you.
Podman mailing list -- podman@lists.podman.io
To unsubscribe send an email to podman-leave@lists.podman.io
Podman mailing list -- podman@lists.podman.io
To unsubscribe send an email to podman-leave@lists.podman.io
Oops, I wrote a typo: Instead of "Passing --uidmap 0:1:$uid translates to: host UID (first subordinate UID) -> intermediate UID (1) -> container UID 1 " it should be "Passing --uidmap 0:1:$uid translates to: host UID (first subordinate UID) -> intermediate UID (1) -> container UID 0 " On Sat, Feb 19, 2022 at 8:19 AM Erik Sjölund <erik.sjolund@gmail.com> wrote:
Why is the user 1000 inside the host mapped to the user 0 (root) on the host (--uidmap $uid:0:1)?
I assume you meant
"Why is the user 1000 inside the container mapped to the user 0 (root) on the host (--uidmap $uid:0:1)?"
The complicated part of using --uidmap together with rootless podman (i.e. running Podman from an unprivileged account), is that the mapping happens over two mappings steps. The first step is handled by Podman itself and can't be controlled by the user. The option --uidmap controls the second mapping step.
So we have two steps:
first mapping second mapping
host UID --> intermediate UID --> container UID
The name "intermediate UID" is just a name to be able to reason about the two mapping steps.
The middle number in --uidmap is actually the intermediate UID when you are running rootless Podman.
In other words --uidmap $uid:0:1 means: map the intermediate UID 0 to the container UID 1000.
Why do we need to pass that option?
The reason for this is that the first mapping step always maps the user's regular host UID to the intermediate UID 0.
For instance if the user's regular UID on the host is 3456 and the container UID is $uid, the command-line argument --uidmap $uid:0:1 would map the host UID 3456 to the container UID $uid
host UID (3456) -> intermediate UID (0) -> container UID ($uid)
If you search for the text string "First mapping step" on the web page https://docs.podman.io/en/latest/markdown/podman-run.1.html#uidmap-container... you will find a table that describes how Podman handles the first mapping step.
Why is the root user inside the container mapped to uid 1 on the host (--uidmap 0:1:$uid)?
The digit 1 actually means intermediate UID 1. The first mapping step mapped the lowest subordinate UID to intermediate UID 1.
Passing
--uidmap 0:1:$uid
translates to:
host UID (first subordinate UID) -> intermediate UID (1) -> container UID 1
The last number in "--uidmap 0:1:$uid", $uid, specifies how many consecutive IDs should be mapped.
Secondly, is there any reason why `:U` option isn't working for me? Is it working for you? No, it didn't work for me. Sorry, I think ":U" is not so useful for the container image docker.io/gogs/gogs
should I file a bug report? I think everything is working as expected so there is no need for that.
On Sat, Feb 19, 2022 at 3:42 AM Prafulla Giri <prafulla.giri@protonmail.com> wrote:
I tried running the shell script you provided, and it does work.
Could you please explain to me what the `--uidmap`s are doing, please? Why is the user 1000 inside the host mapped to the user 0 (root) on the host (--uidmap $uid:0:1)? Why is the root user inside the container mapped to uid 1 on the host (--uidmap 0:1:$uid)? The last one [--uidmap $(($uid+1)):$(($uid+1)):$(($subuidSize-$uid))] seems to be mapping all the rest of the users beyond 1000 to 1000+ on the host, for the entire subuid range. That one makes a bit of sense. (But even then, if I have another user `1001` on the host, that is mapping `1001` inside the container to that user?)
Clearly, there are a lot of gaping holes in my understanding of namespaces. I would really appreciate it if you would point me to the right direction.
Secondly, is there any reason why `:U` option isn't working for me? Is it working for you? If it is not doing what it is supposed to do, should I file a bug report? Likewise with `--userns=keep-id`.
Thank you for your time and patience.
------- Original Message -------
On Saturday, February 19th, 2022 at 2:28 AM, Erik Sjölund <erik.sjolund@gmail.com> wrote:
Prafulla, I did some more testing.
It looks to be working.
w3m was able to browse the web page:
[tester@laptop ~]$ w3m http://localhost:10880
An ssh client was able to connect to the ssh server.
[tester@laptop ~]$ ssh -p 10022 localhost
The authenticity of host '[localhost]:10022 ([::1]:10022)' can't be established.
ED25519 key fingerprint is SHA256:rRXoPCat1mA7cGWCr9TOUxGYzQafFUEr2yXKIH+Oe8w.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[localhost]:10022' (ED25519) to the list
of known hosts.
tester@localhost: Permission denied (publickey,keyboard-interactive).
[tester@laptop ~]$
Maybe you could try the Bash script run.sh and see if it works for you?
Kind regards
Erik Sjölund
On Fri, Feb 18, 2022 at 8:49 PM Erik Sjölund erik.sjolund@gmail.com wrote:
I tried to run this Bash script
#!/bin/bash
uid=1000
gid=1000
subuidSize=$(( $(podman info --format "{{ range
.Host.IDMappings.UIDMap }}+{{.Size }}{{end }}" ) - 1 ))
subgidSize=$(( $(podman info --format "{{ range
.Host.IDMappings.GIDMap }}+{{.Size }}{{end }}" ) - 1 ))
podman run --rm \
-v ./gogs:/data:Z \
--uidmap $uid:0:1 \
--uidmap 0:1:$uid \
--uidmap $(($uid+1)):$(($uid+1)):$(($subuidSize-$uid)) \
--gidmap $gid:0:1 \
--gidmap 0:1:$gid \
--gidmap $(($gid+1)):$(($gid+1)):$(($subgidSize-$gid)) \
--name=gogs -p 10022:22 -p 10880:3000 \
docker.io/gogs/gogs
[tester@laptop ~]$ podman --version
podman version 3.4.4
[tester@laptop ~]$ bash run.sh
usermod: no changes
Feb 18 19:14:58 syslogd started: BusyBox v1.33.1
2022/02/18 19:14:58 [ WARN] Custom config "/data/gogs/conf/app.ini"
not found. Ignore this warning if you're running for the first time
2022/02/18 19:14:58 [TRACE] Log mode: Console (Trace)
2022/02/18 19:14:58 [ INFO] Gogs 0.13.0+dev
2022/02/18 19:14:58 [TRACE] Work directory: /app/gogs
2022/02/18 19:14:58 [TRACE] Custom path: /data/gogs
2022/02/18 19:14:58 [TRACE] Custom config: /data/gogs/conf/app.ini
2022/02/18 19:14:58 [TRACE] Log path: /app/gogs/log
2022/02/18 19:14:58 [TRACE] Build time: 2022-02-14 02:18:07 UTC
2022/02/18 19:14:58 [TRACE] Build commit:
8a1a40ce6a2fcad2ca877c1c98dcf492c5f9fbed
2022/02/18 19:14:58 [ INFO] Run mode: Development
Feb 18 19:14:58 sshd[45]: Server listening on :: port 22.
Feb 18 19:14:58 sshd[45]: Server listening on 0.0.0.0 port 22.
2022/02/18 19:14:58 [ INFO] Listen on http://0.0.0.0:3000
I didn't try connecting with a web browser but at least the file
permissions look OK.
In another shell:
[tester@fcos ~]$ ls -l gogs
total 4
drwxr-xr-x. 3 tester tester 18 Feb 18 19:14 git
drwxr-xr-x. 5 tester tester 41 Feb 18 19:14 gogs
drwx------. 2 tester tester 4096 Feb 18 19:14 ssh
[tester@fcpos ~]$
I haven't figured out yet why adding --user $uid:$gid fails though.
Kind regards,
Erik Sjölund
On Fri, Feb 18, 2022 at 7:54 PM Prafulla Giri
prafulla.giri@protonmail.com wrote:
Hello there,
Thank you for the pointers.
I tried using :U (with Z - :U,Z) and that didn't do the trick.
I also tried using --userns=keep-id, and that also didn't work.
I tried following https://github.com/containers/podman/blob/main/troubleshooting.md#33-contain... and I must admit, while the sample works, I don't understand it enough to translate it to my use case (and it is quite unwieldy). I have a really hard time wrapping my head around what is going on with --uidmap 2003:0:1 (set the user inside the container to map to uid 0 (root?) on the host ?) and another --uidmap 2004:2004:65536 (set the user 20004 onwards to map to uid 2004 on the host)?
This is the exact container/volume that I'm having trouble with:
$ mkdir gogs
$ podman run -v ./gogs:/data docker.io/gogs/gogs
The user `git` inside the container has uid 1000, and is mapped to uid 100999 outside the container. In the end, ./gogs is owned by 100999.
------- Original Message -------
On Wednesday, February 16th, 2022 at 4:19 PM, Erik Sjölund erik.sjolund@gmail.com wrote:
I wrote two troubleshooting tips that describes how --uidmap and
--gidmap can be used to handle situations like that:
https://github.com/containers/podman/blob/main/troubleshooting.md#34-passed-...
https://github.com/containers/podman/blob/main/troubleshooting.md#33-contain...
Another alternative is to use the volume option ":U".
Quote
"The :U suffix tells Podman to use the correct host UID and GID based
on the UID and GID within the container, to change recursively the
owner and group of the source volume."
from
https://docs.podman.io/en/latest/markdown/podman-run.1.html#volume-v-source-...
If you can use --uidmap and --gidmap (or --userns=keep-id), you
probably don't need to run chown or use ":U".
Regards,
Erik Sjölund
On Tue, Feb 15, 2022 at 10:15 PM Prafulla Giri via Podman
podman@lists.podman.io wrote:
> Hello there, > > I have bind-mounted a local dir inside a container. Once the container is closed the directory permissions are > > changed to a subuid and I have to run `podman unshare chown -R 0:0 /path/to/dir` manually if I want to do anything > > with the bind-mounted directory. I was wondering if there is a method whereby a container (or a pod) could be configured > > to do this automatically? I'd be glad to know about it (or any other ways to get around this minor issue). > > Thank you. > > Podman mailing list -- podman@lists.podman.io > > To unsubscribe send an email to podman-leave@lists.podman.io
Podman mailing list -- podman@lists.podman.io
To unsubscribe send an email to podman-leave@lists.podman.io
Hmm... I think I'm starting to get it now. I just ran `$ podman run --rm --uidmap 1000:0:1 --uidmap 0:1:1000 -v ./gogsfoo:/data docker.io/gogs/gogs` and on exit ./gogsfoo is owned by my regular user. I suppose the final `--uidmap 1001:1001:$(($subuidsize-1000))` where $subuidsize is `cat /etc/subuid | cat -d: -f 3` is just a precaution, and my aforementioned command would have failed if there were a user 1001 inside the container, because then podman would be like "I don't know where to map it", I presume? I wonder... if we had something whereby, on exit, podman reverted the ownership of all files in the subuid range (as specified by /etc/subuid) back to the user, automatically (or if there a flag to make it do so), it would be of tremendous help to the users.
On Mon, Feb 21, 2022 at 4:44 AM Prafulla Giri <prafulla.giri@protonmail.com> wrote:
Hmm... I think I'm starting to get it now.
I just ran `$ podman run --rm --uidmap 1000:0:1 --uidmap 0:1:1000 -v ./gogsfoo:/data docker.io/gogs/gogs` and on exit ./gogsfoo is owned by my regular user.
I suppose the final `--uidmap 1001:1001:$(($subuidsize-1000))` where $subuidsize is `cat /etc/subuid | cat -d: -f 3` is just a precaution, and my aforementioned command would have failed if there were a user 1001 inside the container, because then podman would be like "I don't know where to map it", I presume?
Yes, Podman would have problems creating the container if it contains files or directories owned by the user. For instance this Containerfile: FROM docker.io/gogs/gogs RUN useradd -u 1001 -m extrauser leads to this error message $ podman run --rm --uidmap 1000:0:1 --uidmap 0:1:1000 localhost/extra Error: error creating container storage: error creating an ID-mapped copy of layer "12e80c7e88c3f1123da63a0e550344f5360ac54b69543a78a54d7436df781da5": exit status 1: error during chown: error mapping container ID pair idtools.IDPair{UID:1001, GID:1001} for "home/extrauser" to host: Container ID 1001 cannot be mapped to a host ID
I wonder... if we had something whereby, on exit, podman reverted the ownership of all files in the subuid range (as specified by /etc/subuid) back to the user, automatically (or if there a flag to make it do so), it would be of tremendous help to the users.
An alternative could also be to run podman unshare chown -R $(id -u):$(id -g) volumedir/ afterwards.
I see. That makes it quite clear. Thank you very much.
An alternative could also be to run podman unshare chown -R $(id -u):$(id -g) volumedir/ afterwards.
That is why I wanted to know if we could have podman execute manual cleanup commands on exit. I suppose that isn't something others have a need of. P. S: `podman unshare chown -R $(id -u):$(id -g) volumedir` does not quite do the trick. One must `podman unshare chown -R 0:0 volumedir`, as I've been doing (which, turns out, is because of the intermediate-uid-mapping that you explained in this thread).
On Tue, Feb 22, 2022 at 4:41 AM Prafulla Giri <prafulla.giri@protonmail.com> wrote:
I see. That makes it quite clear. Thank you very much.
An alternative could also be to run podman unshare chown -R $(id -u):$(id -g) volumedir/ afterwards.
That is why I wanted to know if we could have podman execute manual cleanup commands on exit. I suppose that isn't something others have a need of.
P. S: `podman unshare chown -R $(id -u):$(id -g) volumedir` does not quite do the trick. One must `podman unshare chown -R 0:0 volumedir`, as I've been doing (which, turns out, is because of the intermediate-uid-mapping that you explained in this thread).
Of course, you're right. I agree, the command is podman unshare chown -R 0:0 volumedir
participants (2)
-
Erik Sjölund -
Prafulla Giri