[GH-ISSUE #1344] Bug: getpwuid(): uid not found: 999 in config.get_system_user() when running in K3S #3840

Closed
opened 2026-03-15 00:39:13 +03:00 by kerem · 3 comments
Owner

Originally created by @darkstar on GitHub (Feb 8, 2024).
Original GitHub issue: https://github.com/ArchiveBox/ArchiveBox/issues/1344

Describe the bug

I am running archivebox in a k3s setup. The last version I successfully used was tagged with sha-c5ccb05 from ~2 years ago.
Now I wanted to update to a more recent version (sha-babd273, which is equal to main at the time of this writing, so it's from Feb. 1st 2024) but I keep getting this error:

[X] Error while loading configuration value: USER
    KeyError: 'getpwuid(): uid not found: 999'

    Check your config for mistakes and try again (your archive data is unaffected).

    For config documentation and examples see:
        https://github.com/ArchiveBox/ArchiveBox/wiki/Configuration

Basically I try running as non-priviledged user 999, which seems to fail. There was one issue (#993) which seems to be the same problem, and apparently that is supposed to be fixed, but the fix doesn't seem to be in the version from 7 days ago?

I have no idea how the config.py script looks like in that version, sice I don't have any means of getting into the container as it keeps stopping/crashing

Steps to reproduce

Run a deployment similar to this in your k3s cluster:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: archive
  namespace: archive
  labels:
    app: archivebox
spec:
  selector:
    matchLabels:
      app: archivebox
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: archivebox
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 999 # this is the UID I want to run the container as, which has worked before
      containers:
      - image: archivebox/archivebox:sha-babd273 # not working
        #image: archivebox/archivebox:sha-c5ccb05 # working
        name: archivebox
        env:
        - name: ALLOWED_HOSTS
          value: "*"
        - name: MEDIA_MAX_SIZE
          value: "1024m"
        - name: PUID   # tried adding this as well, but it didn't change anything
          value: "999" #
        command: ['archivebox']
        args: ['server', '--quick-init', '0.0.0.0:8000'] # tried to change this to `args: [ '--version' ]`  and `args: ['version']` but to no avail
        ports:
        - containerPort: 8000
          name: archivebox
        volumeMounts:
        - name: archive-data
          mountPath: /data
      volumes:
      - name: archive-data
        hostPath:
          path: /mnt/usb/data
          type: Directory

ArchiveBox version

I only have the sha-babd273 from dockerhub, no idea what archivebox version is behind this, and since the container crashes immediately I also cannot enter a shell to inspect it. It looks like the check for the uid is done before the check for the "version" command, so even if I change the startup parameters to

Originally created by @darkstar on GitHub (Feb 8, 2024). Original GitHub issue: https://github.com/ArchiveBox/ArchiveBox/issues/1344 #### Describe the bug I am running archivebox in a k3s setup. The last version I successfully used was tagged with sha-c5ccb05 from ~2 years ago. Now I wanted to update to a more recent version ([sha-babd273](https://hub.docker.com/layers/archivebox/archivebox/sha-babd273/images/sha256-6724df81014bea4d989423ecc61f0949adb0fe4f2c74a5354cf81611fa639db9?context=explore), which is equal to main at the time of this writing, so it's from Feb. 1st 2024) but I keep getting this error: ``` [X] Error while loading configuration value: USER KeyError: 'getpwuid(): uid not found: 999' Check your config for mistakes and try again (your archive data is unaffected). For config documentation and examples see: https://github.com/ArchiveBox/ArchiveBox/wiki/Configuration ``` Basically I try running as non-priviledged user 999, which seems to fail. There was one issue (#993) which seems to be the same problem, and apparently that is supposed to be fixed, but the fix doesn't seem to be in the version from 7 days ago? I have no idea how the config.py script looks like in that version, sice I don't have any means of getting into the container as it keeps stopping/crashing #### Steps to reproduce Run a deployment similar to this in your k3s cluster: ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: archive namespace: archive labels: app: archivebox spec: selector: matchLabels: app: archivebox strategy: type: Recreate template: metadata: labels: app: archivebox spec: securityContext: runAsNonRoot: true runAsUser: 999 # this is the UID I want to run the container as, which has worked before containers: - image: archivebox/archivebox:sha-babd273 # not working #image: archivebox/archivebox:sha-c5ccb05 # working name: archivebox env: - name: ALLOWED_HOSTS value: "*" - name: MEDIA_MAX_SIZE value: "1024m" - name: PUID # tried adding this as well, but it didn't change anything value: "999" # command: ['archivebox'] args: ['server', '--quick-init', '0.0.0.0:8000'] # tried to change this to `args: [ '--version' ]` and `args: ['version']` but to no avail ports: - containerPort: 8000 name: archivebox volumeMounts: - name: archive-data mountPath: /data volumes: - name: archive-data hostPath: path: /mnt/usb/data type: Directory ``` #### ArchiveBox version I only have the sha-babd273 from dockerhub, no idea what archivebox version is behind this, and since the container crashes immediately I also cannot enter a shell to inspect it. It looks like the check for the uid is done before the check for the "version" command, so even if I change the startup parameters to
Author
Owner

@darkstar commented on GitHub (Feb 8, 2024):

I switched to an older container image (sha-4950cee in this case, from 5 months ago) and everything works fine there...

ind: ‘/home/archivebox/.config/chromium/Crash Reports/pending/’: No such file or directory
[i] [2024-02-08 20:34:47] ArchiveBox v0.6.3: archivebox server --quick-init 0.0.0.0:8000
    > /data

find: ‘/home/archivebox/.config/chromium/Crash Reports/pending/’: No such file or directory
[^] Verifying and updating existing ArchiveBox collection to v0.6.3...
----------------------------------------------------------------------

[*] Verifying archive folder structure...
    + ./archive, ./sources, ./logs...
    + ./ArchiveBox.conf...
find: ‘/home/archivebox/.config/chromium/Crash Reports/pending/’: No such file or directory

[*] Verifying main SQL index and running any migrations needed...
    Operations to perform:
    Apply all migrations: admin, auth, contenttypes, core, sessions
    Running migrations:
    Applying core.0021_auto_20220914_0934... OK

    √ ./index.sqlite3

[*] Checking links from indexes and archive folders (safe to Ctrl+C)...
    √ Loaded 52 links from existing main index.
    > Skipping full snapshot directory check (quick mode)

----------------------------------------------------------------------
[√] Done. Verified and updated the existing ArchiveBox collection.

[+] Starting ArchiveBox webserver...
    > Logging errors to ./logs/errors.log
Performing system checks...

System check identified no issues (0 silenced).
February 08, 2024 - 20:34:54
Django version 3.1.14, using settings 'core.settings'
Starting development server at http://0.0.0.0:8000/
Quit the server with CONTROL-C.
<!-- gh-comment-id:1934895315 --> @darkstar commented on GitHub (Feb 8, 2024): I switched to an older container image ([sha-4950cee](https://hub.docker.com/layers/archivebox/archivebox/sha-4950cee/images/sha256-f350d0e2659e2d716dfc240c9032bd87dd6c6664cc96c4ce0c8a434bff7327f7?context=explore) in this case, from 5 months ago) and everything works fine there... ``` ind: ‘/home/archivebox/.config/chromium/Crash Reports/pending/’: No such file or directory [i] [2024-02-08 20:34:47] ArchiveBox v0.6.3: archivebox server --quick-init 0.0.0.0:8000 > /data find: ‘/home/archivebox/.config/chromium/Crash Reports/pending/’: No such file or directory [^] Verifying and updating existing ArchiveBox collection to v0.6.3... ---------------------------------------------------------------------- [*] Verifying archive folder structure... + ./archive, ./sources, ./logs... + ./ArchiveBox.conf... find: ‘/home/archivebox/.config/chromium/Crash Reports/pending/’: No such file or directory [*] Verifying main SQL index and running any migrations needed... Operations to perform: Apply all migrations: admin, auth, contenttypes, core, sessions Running migrations: Applying core.0021_auto_20220914_0934... OK √ ./index.sqlite3 [*] Checking links from indexes and archive folders (safe to Ctrl+C)... √ Loaded 52 links from existing main index. > Skipping full snapshot directory check (quick mode) ---------------------------------------------------------------------- [√] Done. Verified and updated the existing ArchiveBox collection. [+] Starting ArchiveBox webserver... > Logging errors to ./logs/errors.log Performing system checks... System check identified no issues (0 silenced). February 08, 2024 - 20:34:54 Django version 3.1.14, using settings 'core.settings' Starting development server at http://0.0.0.0:8000/ Quit the server with CONTROL-C. ```
Author
Owner

@pirate commented on GitHub (Feb 9, 2024):

Interesting, I've only ever seen this on Windows before.

The error is indicating that ArchiveBox is unable to detect the username that corresponds to uid:999. Detecting a username is not critical, we just use it for debugging purposes, so I added a fallback option and wrapped it in another try: except:.

I just pushed the fix to :dev 19aefc85e6.

Give it ~15min for the auto build to finish, then try pulling and running archivebox/archivebox:dev.

(Obligatory warning that dev is not as thoroughly vetted as main, so it may be worth pulling and testing with an empty collection before you run it with any real data.)

<!-- gh-comment-id:1935267144 --> @pirate commented on GitHub (Feb 9, 2024): Interesting, I've only ever seen this on Windows before. The error is indicating that ArchiveBox is unable to detect the username that corresponds to uid:999. Detecting a username is not critical, we just use it for debugging purposes, so I added a fallback option and wrapped it in another `try: except:`. I just pushed the fix to `:dev` 19aefc85e6c3801ac6c77246c1534fc9758739df. Give it ~15min for the auto build to finish, then try pulling and running `archivebox/archivebox:dev`. (Obligatory warning that `dev` is not as thoroughly vetted as `main`, so it may be worth pulling and testing with an empty collection before you run it with any real data.)
Author
Owner

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

Closing as fixed for now. Comment back if you're still seeing this issue on :dev and I can reopen it.

<!-- gh-comment-id:1972347810 --> @pirate commented on GitHub (Mar 1, 2024): Closing as fixed for now. Comment back if you're still seeing this issue on `:dev` and I can reopen it.
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#3840
No description provided.