[BUG] Permission issues after mounting transcodes to tmpfs

[GoingTime]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

I use docker compose to deploy jellyfin. When I mount tmpfs to /config/cache/transcodes, I notice that all the owners and groups of the /config/cache directory in jellyfin are abc, and only the owner and group of transcodes are root, and the permissions are drwxrwx---，which causes ffmpeg to have no permission to access the transcodes directory.

This is an inconsistent behavior. For newly created folders, some are owned by root and some are owned by abc. For folder permissions, some are drwxrwx--- and some are drwxr-xr-x, which will lead to confusing permission problems.

I suggest using some kind of script to automatically configure the owner and permissions of the newly mounted folder when jellfyin is initialized to avoid permission problems. Or recheck the code related to owner and permission configuration.

Expected Behavior

No response

Steps To Reproduce

# docker compose

version: "3.8"
services:
  jellyfin:
    image: lscr.io/linuxserver/jellyfin:latest
    container_name: jellyfin
    restart: unless-stopped
    environment:
      - PUID=568
      - PGID=568
      devices:
      - /dev/dri:/dev/dri
    volumes:
      - /mnt/containers/jellyfin:/config
      - /mnt/videos:/data/videos
      - type: tmpfs
        target: /config/cache/transcodes
        tmpfs:
          size: 8G

# ls -l /config/cache

drwxrwx---  5 abc  abc    5 Sep  7 19:52 attachments
drwxrwx--- 29 abc  abc   29 Sep  7 19:31 audiodb-artist
drwxrwx--- 15 abc  abc   15 Sep  7 19:29 extracted-audio-images
drwxrwx---  3 abc  abc    3 Sep  7 19:36 images
drwxrwx---  2 abc  abc    3 Sep  7 19:32 imagesbyname
drwxrwx---  2 abc  abc   16 Sep  7 19:30 omdb
drwxrwx---  2 abc  abc  196 Sep  7 19:41 temp
drwxrwx---  2 root root  40 Sep  7 20:32 transcodes

# ls -l /data
total 1
drwxr-xr-x 3 root root 3 Sep  7 20:32 videos

Environment

- OS: TrueNAS SCALE 24.10 BETA.1 base Debian 12

CPU architecture

x86-64

Docker creation

Please see "Steps To Reproduce".

Container logs

null

[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.

[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.

[latel]

Stream mapping:
  Stream #0:0 -> #0:0 (hevc (native) -> hevc (hevc_qsv))
  Stream #0:1 -> #0:1 (ac3 (native) -> aac (libfdk_aac))
Press [q] to stop, [?] for help
[hls @ 0x5644bdf7e400] Opening '/config/cache/transcodes/f071b2b6722c5cd7464ffd32b3db4635-1.mp4' for writing
[hls @ 0x5644bdf7e400] Failed to open segment 'f071b2b6722c5cd7464ffd32b3db4635-1.mp4'
[out#0/hls @ 0x5644bdf81a40] Could not write header (incorrect codec parameters ?): Permission denied
[vf#0:0 @ 0x5644c50d4440] Error sending frames to consumers: Permission denied
[vf#0:0 @ 0x5644c50d4440] Task finished with error code: -13 (Permission denied)
[vf#0:0 @ 0x5644c50d4440] Terminating thread with return code -13 (Permission denied)
[out#0/hls @ 0x5644bdf81a40] Nothing was written into output file, because at least one of its streams received no packets.
frame=    0 fps=0.0 q=0.0 Lsize=       0KiB time=N/A bitrate=N/A speed=N/A    
Conversion failed!

I got the same issue, have you solve this?

[latel]

@GoingTime FYI, I solved this by adding --tmpfs /config/cache/transcodes:uid=99,gid=100 according to docker/compose#3425 (comment), change uid and gid as you need.