`init-directories` unconditional `chown -R` on large NFS volumes causes indefinite pod initialization

[amedranogil]

Affected deployments: lidarr, radarr, sonarr (any app that mounts the shared media PVC)

Template location: e.g. charts/servarr/templates/lidarr/deployment.yaml

Current behaviour:

initContainers:
  - name: init-directories
    image: busybox
    command:
      - sh
      - -c
      - mkdir -p /media/MP3 /media/.downloads && chown -R 1000:1000 /media/MP3 /media/.downloads

The chown -R runs unconditionally on every pod start, regardless of whether the files
are already owned by the correct UID/GID. On a large NFS share (e.g. 10 TiB, ~30 k files
across the targeted subdirectories) this results in pods staying in Init:0/1 for tens of
minutes or longer, as every fchownat call is a round-trip to the NFS server.

Suggested fix:

Make the chown conditional, controlled by a value such as lidarr.persistence.chownMedia
(default true). Users users with large pre-existing volumes can set it to false, and won't be blocked on startup.

# values.yaml
lidarr:
  persistence:
    chownMedia: true   # set to false to avoid runing chown -R on the media subdirectory at startup

# deployment.yaml
- name: init-directories
  command:
    - sh
    - -c
    - >-
      mkdir -p /media/{{ .Values.lidarr.persistence.path }} /media/{{ .Values.qbittorrent.persistence.path }}
      {{- if .Values.lidarr.persistence.chownMedia }}
      && chown -R 1000:1000 /media/{{ .Values.lidarr.persistence.path }} /media/{{ .Values.qbittorrent.persistence.path }}
      {{- end }}

Alternative fix:
Make init-directories command conditional to jellyfin.persistence.media.existingClaim existing. So if the stack is based on an existing claim it is expected that those directories are already initialized.