[BUG] Latest version fails to initialize

[dragomirweb]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Fails to start the container , server is down port and web interface

Expected Behavior

Working fine with the prev version: 1.32.5

Steps To Reproduce

1. OS Linux 6.1.0-0.deb11.7-amd64
2. Portainer w/ Docker version 24.0.4, build 3713ee1
3. run my docker compose or I believe any config with latest version

Environment

- OS: Open Media Vault
- How docker service was installed:  Portainer w/ Docker version 24.0.4, build 3713ee1

CPU architecture

x86-64

Docker creation

My docker compose: 
version: "3.8"
services:
  plex:
    image: lscr.io/linuxserver/plex:latest
    container_name: plex
    network_mode: host
    privileged: false
    deploy: # ADD this section
      resources:
        reservations:
          devices:
            - capabilities: [gpu]
    environment:
      - PUID=1000
      - PGID=1000
      - VERSION=docker
      - PLEX_CLAIM=XXXX
      - NVIDIA_VISIBLE_DEVICES=all
      - NVIDIA_DRIVER_CAPABILITIES=compute,video,utility
    volumes:
      - /srv/dev-disk-by-uuid-0f673b39-362b-4182-a9af-62511d769bc2/configs/plex:/config
      - /srv/dev-disk-by-uuid-0f673b39-362b-4182-a9af-62511d769bc2/media/TV:/tv
      - /srv/dev-disk-by-uuid-0f673b39-362b-4182-a9af-62511d769bc2/media/Movies:/movies
      - /srv/dev-disk-by-uuid-0f673b39-362b-4182-a9af-62511d769bc2/media/Music:/music
      - /srv/dev-disk-by-uuid-0f673b39-362b-4182-a9af-62511d769bc2/media/cursuri:/cursuri
    devices:
      - /dev/nvidia0
      - /dev/nvidiactl
      - /dev/nvidia-uvm
    restart: unless-stopped

Container logs

[migrations] started
[migrations] no migrations found
───────────────────────────────────────
      ██╗     ███████╗██╗ ██████╗ 
      ██║     ██╔════╝██║██╔═══██╗
      ██║     ███████╗██║██║   ██║
      ██║     ╚════██║██║██║   ██║
      ███████╗███████║██║╚██████╔╝
      ╚══════╝╚══════╝╚═╝ ╚═════╝ 
   Brought to you by linuxserver.io
───────────────────────────────────────
To support LSIO projects visit:
https://www.linuxserver.io/donate/
───────────────────────────────────────
GID/UID
───────────────────────────────────────
User UID:    1000
User GID:    1000
───────────────────────────────────────

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[Kirri777]

I have encountered the same issue. If you add the comment on network_mode: host and add the necessary ports, Plex will function correctly. However, please note that this solution will disable Nvidia support.

[aptalca]

Due to a bug in our global chown wrapper, latest plex is chowning the whole config folder, so it may take longer to start. A fix is in the works and should get pushed soon.

[leprechaun17]

Due to a bug in our global chown wrapper, latest plex is chowning the whole config folder, so it may take longer to start. A fix is in the works and should get pushed soon.

Agreed, it took about 10 mins to initialize.

[yashgupta-112]

Is there an estimated time for when this issue will be resolved? the issue persists in version 1.32.5 as well.

[justinnichols]

And to add, all of the sudden, this Plex container is now spiking CPU with some shfs process. I shut down the container, the shfs process goes away. I start it back up, the shfs process again starts back up and eats up very high CPU. What is going on?

EDIT>> The shfs issue may have to do with my cache pool in UnRaid having way more data on it than normal, but it's still odd. I'm running the mover in the hopes that this resolves itself (iowait/etc). For now, best to ignore this comment since I cannot assume the shfs issue is strictly Plex container related and not simply an iowait issue.

[LinuxServer-CI]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[panderssanders]

I have a similar issue that is probably related to this problem:
When starting the container the log says that it detected a change in ownership and chowns all config files. But it is chowning the files for a user that does not exist and therefore removes all permissions for the container to access the files itself. After that it prints an error in a loop until I manually correct the permissions for the docker user again. I reverted the container to 1.32.5.7349-8f4248874-ls178 and it is working as expected again.

[aptalca]

Please open a new issue and fill out the template.

The original issue reported here was fixed a while back.