[GH-ISSUE #1379] Support: podman-compose rootless setup leads to PUID=0 being passed, and ArchiveBox refuses to start as root #3862

Closed
opened 2026-03-15 00:44:19 +03:00 by kerem · 9 comments
Owner

Originally created by @sodamouse on GitHub (Mar 13, 2024).
Original GitHub issue: https://github.com/ArchiveBox/ArchiveBox/issues/1379

Describe the bug

When using the default docker-compose.yml file with docker-compose or podman-compose (rootless), the environment variables for PUID and GUID are not honored and installation exits complaining about being run as root.

Steps to reproduce

  • Download official docker-compse file
  • Set PUID/GUID to the output of id -u and id -g (manually)
  • docker-compose run archivebox init --setup

Screenshots or log output

compose file:

...
environment:
        - ALLOWED_HOSTS=*                   # restrict this to only accept incoming traffic via specific domain name
        # - PUBLIC_INDEX=True               # set to False to prevent anonymous users from viewing snapshot list
        # - PUBLIC_SNAPSHOTS=True           # set to False to prevent anonymous users from viewing snapshot content
        # - PUBLIC_ADD_VIEW=False           # set to True to allow anonymous users to submit new URLs to archive
        # - ADMIN_USERNAME=admin            # create an admin user on first run with the given user/pass combo
        # - ADMIN_PASSWORD=SomeSecretPassword
        - PUID=3330
        - PGID=3331

error:

podman run --name=databases_archivebox_tmp42009 -i --pod=databases --label io.podman.compose.config-hash=123 --label io.podman.compose.project=databases --label io.podman.compose.version=0.0.1 --label com.docker.compose.project=databases --label com.docker.compose.project.working_dir=/mnt/mpathh/{username}/databases --label com.docker.compose.project.config_files=docker-compose.yml --label com.docker.compose.container-number=1 --label com.docker.compose.service=archivebox -e ALLOWED_HOSTS=* -e PUID=0 -e PGID=0 -v /mnt/mpathh/{username}/databases/data:/data --tty archivebox/archivebox:dev init --setup

[X] Error: Got PUID=0 and PGID=0 but ArchiveBox is not allowed to be run as root, please change or unset PUID & PGID and try again.
    Hint: some NFS/SMB/FUSE/etc. filesystems force-remap/ignore all permissions,
          leave PUID/PGID unset, disable root_squash, or use values the drive prefers (default is 911:911)
    https://linux.die.net/man/8/mount.cifs#:~:text=does%20not%20provide%20unix%20ownership

ArchiveBox version

I can't get version due to error preventing executing archivebox. But using latest docker image from 2024-03-13.
Originally created by @sodamouse on GitHub (Mar 13, 2024). Original GitHub issue: https://github.com/ArchiveBox/ArchiveBox/issues/1379 #### Describe the bug When using the default docker-compose.yml file with docker-compose or podman-compose (rootless), the environment variables for PUID and GUID are not honored and installation exits complaining about being run as root. #### Steps to reproduce - Download official docker-compse file - Set PUID/GUID to the output of id -u and id -g (manually) - docker-compose run archivebox init --setup #### Screenshots or log output compose file: ```yml ... environment: - ALLOWED_HOSTS=* # restrict this to only accept incoming traffic via specific domain name # - PUBLIC_INDEX=True # set to False to prevent anonymous users from viewing snapshot list # - PUBLIC_SNAPSHOTS=True # set to False to prevent anonymous users from viewing snapshot content # - PUBLIC_ADD_VIEW=False # set to True to allow anonymous users to submit new URLs to archive # - ADMIN_USERNAME=admin # create an admin user on first run with the given user/pass combo # - ADMIN_PASSWORD=SomeSecretPassword - PUID=3330 - PGID=3331 ``` error: ```bash podman run --name=databases_archivebox_tmp42009 -i --pod=databases --label io.podman.compose.config-hash=123 --label io.podman.compose.project=databases --label io.podman.compose.version=0.0.1 --label com.docker.compose.project=databases --label com.docker.compose.project.working_dir=/mnt/mpathh/{username}/databases --label com.docker.compose.project.config_files=docker-compose.yml --label com.docker.compose.container-number=1 --label com.docker.compose.service=archivebox -e ALLOWED_HOSTS=* -e PUID=0 -e PGID=0 -v /mnt/mpathh/{username}/databases/data:/data --tty archivebox/archivebox:dev init --setup [X] Error: Got PUID=0 and PGID=0 but ArchiveBox is not allowed to be run as root, please change or unset PUID & PGID and try again. Hint: some NFS/SMB/FUSE/etc. filesystems force-remap/ignore all permissions, leave PUID/PGID unset, disable root_squash, or use values the drive prefers (default is 911:911) https://linux.die.net/man/8/mount.cifs#:~:text=does%20not%20provide%20unix%20ownership ``` #### ArchiveBox version <!-- Run the `archivebox version` command locally then copy paste the result here: --> ```logs I can't get version due to error preventing executing archivebox. But using latest docker image from 2024-03-13. ``` <!-- Tickets without full version info will closed until it is provided, we need the full output here to help you solve your issue -->
kerem closed this issue 2026-03-15 00:44:24 +03:00
Author
Owner

@pirate commented on GitHub (Mar 14, 2024):

You have these flags -e PUID=0 -e PGID=0 above in the podman command you shared (which supersede any values set in docker-compose.yml).

image

Can you try again without those flags?

<!-- gh-comment-id:1996871409 --> @pirate commented on GitHub (Mar 14, 2024): You have these flags `-e PUID=0 -e PGID=0` above in the podman command you shared (which supersede any values set in `docker-compose.yml`). ![image](https://github.com/ArchiveBox/ArchiveBox/assets/511499/8adae621-1c32-4515-9f8d-03892cff3dee) Can you try again without those flags?
Author
Owner

@sodamouse commented on GitHub (Mar 14, 2024):

You have these flags -e PUID=0 -e PGID=0 above in the podman command you shared (which supersede any values set in docker-compose.yml).

image

Can you try again without those flags?

I'm not the one who is inserting those. That command is what is generated when I run docker-compose up.

<!-- gh-comment-id:1997731655 --> @sodamouse commented on GitHub (Mar 14, 2024): > You have these flags `-e PUID=0 -e PGID=0` above in the podman command you shared (which supersede any values set in `docker-compose.yml`). > > ![image](https://private-user-images.githubusercontent.com/511499/312762888-8adae621-1c32-4515-9f8d-03892cff3dee.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTA0MzA1MzgsIm5iZiI6MTcxMDQzMDIzOCwicGF0aCI6Ii81MTE0OTkvMzEyNzYyODg4LThhZGFlNjIxLTFjMzItNDUxNS05ZjhkLTAzODkyY2ZmM2RlZS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwMzE0JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDMxNFQxNTMwMzhaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT05YzdlOWNhODg0ODJmMGI2MjljOWFmYTMzOTg5ZmM2ZjE1YTExYjI4YTZkOGFhMTJlMDVlZGE5MGMzY2RhYWRkJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.Ym7lX1ohQjuuOja11ODRCMWA9MQSJYmwBy4v-iOCmzU) > > Can you try again without those flags? I'm not the one who is inserting those. That command is what is generated when I run docker-compose up.
Author
Owner

@pirate commented on GitHub (Mar 14, 2024):

Whatever is generating that command is your culprit, it's not controlled by archivebox and is definitely not what's run by standard docker compose up.

I haven't used podman much, but it looks like it could probably be a podman thing modifying the default docker compose setup?

<!-- gh-comment-id:1997996178 --> @pirate commented on GitHub (Mar 14, 2024): Whatever is generating that command is your culprit, it's not controlled by archivebox and is definitely not what's run by standard docker compose up. I haven't used podman much, but it looks like it could probably be a podman thing modifying the default docker compose setup?
Author
Owner

@sodamouse commented on GitHub (Mar 14, 2024):

It's possible but i don't have any control over it. Podman is rootless, so anything that get executed is not actually being run as root, but having PUID=0 in the container throws off archivebox i suppose.

<!-- gh-comment-id:1998430332 --> @sodamouse commented on GitHub (Mar 14, 2024): It's possible but i don't have any control over it. Podman is rootless, so anything that get executed is not actually being run as root, but having PUID=0 in the container throws off archivebox i suppose.
Author
Owner

@pirate commented on GitHub (Mar 14, 2024):

ArchiveBox always tries to drop down to a non-privileged user, as we don't allow running it as root for security reasons. There's just too many 3rd-party dependencies used and too much shell execution->downloading->parsing RCE escalation risk to allow running extractors as root, even inside a container.

If you pass PUID=0 it will refuse to run because that's not a non-privileged user.

If you pass a valid, non-root PUID (ideally >500, lower UIDs may behave strangely), it will set the archivebox user use that uid and drop down to that user to run the archiving processes.

https://github.com/ArchiveBox/ArchiveBox/wiki/Security-Overview#do-not-run-as-root

<!-- gh-comment-id:1998493069 --> @pirate commented on GitHub (Mar 14, 2024): ArchiveBox always tries to drop down to a non-privileged user, as we don't allow running it as root for security reasons. There's just too many 3rd-party dependencies used and too much shell execution->downloading->parsing [RCE](https://www.cloudflare.com/learning/security/what-is-remote-code-execution/) escalation risk to allow running extractors as root, even inside a container. If you pass `PUID=0` it will refuse to run because that's not a non-privileged user. If you pass a valid, non-root `PUID` (ideally `>500`, lower UIDs may behave strangely), it will set the `archivebox` user use that uid and drop down to that user to run the archiving processes. https://github.com/ArchiveBox/ArchiveBox/wiki/Security-Overview#do-not-run-as-root
Author
Owner

@sodamouse commented on GitHub (Mar 16, 2024):

You reasoning is sound and i understand it, however this makes the docker solution unusable in my environment. I will look into how to disable this check.

WindowsTerminal_r8aP8onK6R

This is what's happening -> docker invokes podman, podman runs everything in a rootless environment (where the user has the PUID=0, but has no actual system-level root access). This trips up the check in archivebox.

Anyways, this is only a "bug" in so far as PUID=0 doesn't always mean root. If it's out of scope, please close this ticket.

<!-- gh-comment-id:2002048920 --> @sodamouse commented on GitHub (Mar 16, 2024): You reasoning is sound and i understand it, however this makes the docker solution unusable in my environment. I will look into how to disable this check. ![WindowsTerminal_r8aP8onK6R](https://github.com/ArchiveBox/ArchiveBox/assets/112235696/94c48534-a912-4da3-a34d-af89ada74083) This is what's happening -> docker invokes podman, podman runs everything in a rootless environment (where the user has the PUID=0, but has no actual system-level root access). This trips up the check in archivebox. Anyways, this is only a "bug" in so far as PUID=0 doesn't always mean root. If it's out of scope, please close this ticket.
Author
Owner

@pirate commented on GitHub (Mar 17, 2024):

As a workaround you can use docker exec instead of docker run / modify the entry point to not run ./bin/docker_entrypoint.sh (which is where the PUID/PGID enforcement checks live).

You'll need to add --user=archivebox to any docker run commands manually or do something like this in docker-compose.yml to make sure ArchiveBox still runs as a non-root user:

services:
    archivebox:
        ...
        entrypoint: /bin/bash
        user: archivebox
<!-- gh-comment-id:2002592130 --> @pirate commented on GitHub (Mar 17, 2024): As a workaround you can use `docker exec` instead of `docker run` / modify the entry point to not run `./bin/docker_entrypoint.sh` (which is where the `PUID`/`PGID` enforcement checks live). You'll need to add `--user=archivebox` to any `docker run` commands manually or do something like this in `docker-compose.yml` to make sure ArchiveBox still runs as a non-root user: ```yaml services: archivebox: ... entrypoint: /bin/bash user: archivebox ```
Author
Owner

@pirate commented on GitHub (Mar 21, 2024):

I can't find any reference to PUID/PGID tampering in the podman-compose codebase, are you adding this part yourself PUID=$(id -u) anywhere?

https://github.com/search?q=repo%3Acontainers%2Fpodman-compose+puid&type=code

This is what's happening -> docker invokes podman, podman runs everything in a rootless environment (where the user has the PUID=0, but has no actual system-level root access

But how are the explicit 3331 values you put in docker-compose.yml getting replaced with $(id -u), what part of the stack would make such a bold change to a user-provided config value?

PUID/PGID are just a convention started by linuxserver.io, they're not even part of any real OCI/Docker spec that would imply they're safe to tamper with at the hypervisor/orchestrator level. It would be very surprising to learn either Docker or Podman have hardcoded in behavior that forcibly edits these env vars.

Also not sure I understand how Docker ends up triggering podman commands, are you running podman inside docker? If so I'd love to learn more about your experiences doing that, because I might be interested in packaging parts of ArchiveBox as podman sub-containers within a main all-batteries-included container (to avoid needing Kubernetes as we grow).


I'm going to close this for now since it's not really a problem with ArchiveBox per-se, but I do love devops spelunking and I am still curious, so if you're willing to share more about your setup I'd be happy to keep investigating and help find a solution in the comments here.

<!-- gh-comment-id:2011169422 --> @pirate commented on GitHub (Mar 21, 2024): I can't find any reference to `PUID`/`PGID` tampering in the `podman-compose` codebase, are you adding this part yourself `PUID=$(id -u)` anywhere? https://github.com/search?q=repo%3Acontainers%2Fpodman-compose+puid&type=code > This is what's happening -> docker invokes podman, podman runs everything in a rootless environment (where the user has the PUID=0, but has no actual system-level root access But how are the explicit `3331` values you put in `docker-compose.yml` getting replaced with `$(id -u)`, what part of the stack would make such a bold change to a user-provided config value? `PUID`/`PGID` are just a convention started by linuxserver.io, they're not even part of any real OCI/Docker spec that would imply they're safe to tamper with at the hypervisor/orchestrator level. It would be very surprising to learn either Docker or Podman have hardcoded in behavior that forcibly edits these env vars. Also not sure I understand how Docker ends up triggering podman commands, are you running podman *inside* docker? If so I'd love to learn more about your experiences doing that, because I might be interested in packaging parts of ArchiveBox as podman sub-containers within a main all-batteries-included container (to avoid needing Kubernetes as we grow). --- I'm going to close this for now since it's not really a problem with ArchiveBox per-se, but I do love devops spelunking and I am still curious, so if you're willing to share more about your setup I'd be happy to keep investigating and help find a solution in the comments here.
Author
Owner

@sodamouse commented on GitHub (Mar 21, 2024):

Hi, the issue is that this setup is not managed by me. It's managed by a provider, so unfortunately i can't provide you info beyond guesswork. All I can say is that I am not adding PUID=$(id -u) myself, and that I believe podman is indeed being run inside docker.

<!-- gh-comment-id:2013463454 --> @sodamouse commented on GitHub (Mar 21, 2024): Hi, the issue is that this setup is not managed by me. It's managed by a provider, so unfortunately i can't provide you info beyond guesswork. All I can say is that I am not adding `PUID=$(id -u)` myself, and that I believe podman is indeed being run inside docker.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/ArchiveBox#3862
No description provided.