Cómo restaurar los permisos de Jellyfin después de mover su directorio de datos

Después de mover el directorio de datos de Jellyfin, restaura los permisos haciendo coincidir los archivos movidos con la identidad que realmente ejecuta Jellyfin y confirmando que el contenedor o servicio apunta a la ruta prevista. No empieces con chmod -R 777.

Una migración puede cambiar la propiedad numérica, las ACL heredadas, las opciones de montaje, las etiquetas de SELinux o el UID/GID utilizado por un contenedor recreado. Diagnostica esas capas en ese orden, corrige únicamente los datos propiedad de Jellyfin, inicia el servidor y verifica las escrituras de la base de datos, los metadatos, las copias de seguridad y las tareas programadas antes de modificar los permisos de la biblioteca multimedia.

Confirma la nueva ruta y la identidad de ejecución de Jellyfin

Detén Jellyfin antes de reparar los datos de la aplicación movidos para que las escrituras en segundo plano no interfieran con la inspección. Confirma la nueva ruta del host, la ruta que Jellyfin ve dentro del contenedor o servicio y el UID/GID de la identidad de Jellyfin en ejecución.

La guía de migración de Jellyfin recomienda determinar el uid y el gid del usuario de Jellyfin y conservar las rutas previstas durante la migración. Guía de UID/GID para la migración de Jellyfin

Si el contenedor apunta al directorio equivocado del host, corrige primero el montaje. Los permisos no pueden reparar una asignación de rutas que dirija Jellyfin a una carpeta vacía, y comenzar con esa ruta vacía puede crear un segundo árbol de datos nuevo.

Inspecciona la propiedad, los bits de modo y las ACL antes de cambiarlos

Enumera el propietario y el grupo numéricos del directorio movido y de una muestra de sus subdirectorios de base de datos, configuración, metadatos y registros. Comprueba los permisos de ejecución de los directorios padre y cualquier entrada de ACL que pueda haberse heredado del sistema de archivos de destino.

Una migración a un NAS puede introducir un modelo diferente de identidad y permisos, especialmente cuando intervienen SMB, NFS o contenedores. La guía de diagnóstico de permisos tras una migración de ZimaSpace explica por qué un montaje visible no evita la autorización basada en UID/GID del proceso del contenedor.

No cambies nada hasta poder describir la discrepancia con precisión: propietario incorrecto, acceso de grupo ausente, recorrido bloqueado del directorio padre, ACL inesperada o montaje de solo lectura. Esa descripción determina la reparación segura más pequeña.

Restaura la propiedad únicamente en los datos de la aplicación propiedad de Jellyfin

Si se supone que el directorio de datos movido de Jellyfin pertenece a la cuenta de servicio de Jellyfin, restaura ese propietario y grupo previstos en todo ese árbol de datos de la aplicación. Conserva la propiedad de los archivos multimedia compartidos que no estén relacionados, salvo que Jellyfin realmente necesite administrarlos.

La documentación de migración de Jellyfin incluye la corrección de la propiedad del directorio de datos de Jellyfin después de una migración. Corrección de la propiedad después de la migración Trátalo como una operación específica sobre los datos de la aplicación, no como un motivo para asumir recursivamente la propiedad de un recurso compartido NAS completo.

Después de corregir la propiedad, vuelve a inspeccionar una muestra y realiza una comprobación de escritura no destructiva, como la identidad de Jellyfin, en un subdirectorio de prueba dedicado. Si la escritura sigue denegada, deja de añadir cambios de chmod e inspecciona las ACL, el modo de montaje o las etiquetas de seguridad.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Comprueba el modo de montaje del contenedor y las etiquetas de seguridad

Un propietario correcto en el host aún puede fallar dentro de un contenedor si el montaje enlazado es de solo lectura, el usuario de ejecución cambió o el sistema de seguridad del host bloquea la ruta. Compara la definición actual del contenedor con la última que funcionaba.

La guía de contenedores de Jellyfin muestra la ejecución explícita mediante UID/GID, montajes de medios de solo lectura y opciones de relabelado de Podman para entornos SELinux. Permisos y relabelado de contenedores Estos controles pueden prevalecer sobre lo que aparentemente permiten los bits de modo Unix normales.

Cambia únicamente la capa confirmada. Haz que el montaje de los datos de la aplicación sea escribible si Jellyfin necesita escribir allí, restaura el UID/GID de ejecución correcto o aplica la etiqueta adecuada para la plataforma a ese montaje. Después, recrea el contenedor una vez y vuelve a comprobar la misma ruta desde su interior.

Inicia Jellyfin y verifica las escrituras de la base de datos y del directorio de datos

Inicia Jellyfin y sigue el registro de arranque. Confirma que abre el estado existente del servidor en lugar de mostrar un asistente de configuración o una biblioteca vacía, y busca errores de permisos relacionados con la base de datos, la configuración, los metadatos o los registros.

Si el inicio llega al panel normal, activa una operación de bajo riesgo que escriba en el estado propiedad de Jellyfin, como una tarea programada o una acción de metadatos en un contexto de prueba, y confirma que el archivo o estado de la base de datos esperado cambia sin errores de permisos.

Reinicia Jellyfin una vez más. La reparación solo está completa si el mismo directorio de datos se abre correctamente después de un inicio nuevo; el éxito en una sola sesión puede ocultar un problema de montaje o inicialización que reaparezca al recrear el contenedor.

Revierte los cambios generales y escala el problema con pruebas exactas

Si ya aplicaste permisos recursivos generales y el servidor sigue fallando, no continúes ampliando el acceso. Restaura, cuando sea posible, la propiedad registrada o una copia de seguridad y vuelve a analizar la discrepancia específica entre la identidad de ejecución y la ruta.

En servidores en contenedores, compara el origen del montaje actual, el destino, el UID/GID, los grupos y el contexto de seguridad con la definición de trabajo guardada. En instalaciones nativas, compara la identidad del servicio y el comportamiento del montaje y las ACL del sistema de archivos de destino. El objetivo es obtener un modelo de permisos único y explicable.

Detente cuando Jellyfin abra la base de datos original, escriba en sus propios directorios de datos, complete la operación en segundo plano elegida y sobreviva a un reinicio. Escala el problema proporcionando la propiedad numérica, la salida de las ACL, las opciones de montaje, el UID/GID de ejecución y el primer error de permisos del registro, si alguna de esas comprobaciones sigue fallando.