Cómo restaurar los permisos de Jellyfin después de mover su directorio de datos
Después de trasladar el directorio de datos de Jellyfin, restablece los permisos haciendo coincidir los archivos trasladados 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.
Un traslado puede cambiar la propiedad numérica, las ACL heredadas, las opciones de montaje, las etiquetas SELinux o el UID/GID utilizado por un contenedor recreado. Diagnostica esas capas en ese orden, corrige solo los datos que pertenecen a Jellyfin y luego inicia el servidor y verifica las escrituras en la base de datos, los metadatos, las copias de seguridad y las tareas programadas antes de tocar 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 trasladados para evitar que las escrituras en segundo plano coincidan 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 con la que se ejecuta Jellyfin.
Las instrucciones de migración de Jellyfin recomiendan explícitamente determinar el uid y el gid del usuario de Jellyfin y conservar las rutas previstas durante la migración. Instrucciones de Jellyfin sobre UID/GID para la migración
Si el contenedor apunta al directorio incorrecto del host, corrige primero el montaje. Los permisos no pueden reparar una asignación de ruta que dirija Jellyfin a una carpeta vacía, y al iniciarse 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 trasladado y de una muestra de sus subdirectorios de bases de datos, configuración, metadatos y registros. Comprueba los permisos de ejecución de los directorios superiores y las entradas ACL que puedan haberse heredado del sistema de archivos de destino.
Un traslado a un NAS puede introducir un modelo de identidad y permisos diferente, especialmente si intervienen SMB, NFS o contenedores. El diagnóstico de permisos después del traslado de ZimaSpace explica por qué un montaje visible no elude la autorización UID/GID del proceso del contenedor.
No cambies nada hasta que puedas describir el problema con precisión: propietario incorrecto, falta de acceso al grupo, acceso bloqueado a un directorio superior, ACL inesperada o montaje de solo lectura. Esa descripción determina cuál es la reparación segura más pequeña.
Restablece la propiedad solo en los datos de la aplicación pertenecientes a Jellyfin
Si se supone que la cuenta de servicio de Jellyfin debe ser propietaria del directorio de datos trasladado, restablece ese propietario y grupo previstos en ese árbol de datos de la aplicación. Conserva la propiedad de los archivos multimedia compartidos que no estén relacionados, a menos que Jellyfin realmente necesite administrar esos archivos.
La documentación de migración de Jellyfin incluye corregir la propiedad del directorio de datos de Jellyfin después de trasladarlo. corregir la propiedad después de la migración Considéralo una operación específica sobre los datos de la aplicación, no un motivo para cambiar recursivamente la propiedad de todo un recurso compartido del NAS.
Tras corregir la propiedad, vuelve a inspeccionar un ejemplo y comprueba, sin modificar datos, si la identidad de Jellyfin puede escribir en un subdirectorio de prueba específico. Si se sigue denegando la escritura, deja de cambiar los permisos con chmod y comprueba las ACL, el modo de montaje o las etiquetas de seguridad.
Comprueba el modo de montaje del contenedor y las etiquetas de seguridad
Aunque el propietario en el host sea correcto, puede haber errores dentro de un contenedor si el montaje enlazado es de solo lectura, ha cambiado el usuario en tiempo de ejecución 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 con UID/GID explícitos, los montajes de medios de solo lectura y las opciones de reetiquetado de Podman para entornos SELinux. permisos de contenedores y reetiquetado Estos controles pueden prevalecer sobre lo que parecen permitir los bits de permisos Unix habituales.
Cambia solo la capa que hayas confirmado. Haz que el montaje de datos de la aplicación permita la escritura si Jellyfin debe escribir ahí, restaura el UID/GID correcto en tiempo de ejecución o aplica a ese montaje la etiqueta adecuada para la plataforma. Después, recrea el contenedor una vez y vuelve a comprobar la misma ruta desde su interior.
Inicia Jellyfin y verifica las escrituras en la base de datos y el directorio de datos
Inicia Jellyfin y sigue el registro de inicio. Confirma que abre el estado existente del servidor, en lugar de un asistente de configuración o una biblioteca vacía, y busca errores de permisos en la base de datos, la configuración, los metadatos o los registros.
Si el inicio llega al panel de control habitual, 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 entorno de prueba, y confirma que cambie el archivo o el estado de la base de datos esperado sin errores de permisos.
Reinicia Jellyfin una vez más. La reparación solo está completa si el mismo directorio de datos se abre sin problemas tras un nuevo inicio; un éxito en una sola sesión puede ocultar un problema de montaje o inicialización que reaparezca al recrear el contenedor.
Revierte los cambios amplios y escala con pruebas concretas
Si ya aplicaste permisos recursivos amplios y el servidor sigue sin funcionar, no sigas ampliando el acceso. Siempre que sea posible, restaura la propiedad registrada o una copia de seguridad; después, vuelve a revisar la identidad específica en tiempo de ejecución y la discrepancia de rutas.
En servidores en contenedores, compara el origen y el destino del montaje actuales, 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 de montaje y ACL del sistema de archivos de destino. El objetivo es contar con un modelo de permisos que se pueda explicar.
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 se reinicie sin problemas. Si alguna de esas comprobaciones sigue fallando, recopila el propietario numérico, la salida de las ACL, las opciones de montaje, el UID/GID en tiempo de ejecución y el primer error de permisos del registro, si lo hay.
Productos recomendados
Soporte y consejos
Más para leer
Qué comprobar antes de cargar un modelo de la comunidad en Transformers
Usa la actualización del entorno aislado de Jinja para Transformers para revisar la procedencia del modelo, las plantillas de chat, el código remoto, los...
Ejecuta Mirage localmente: OCR y detección de objetos a partir de una sola imagen
Prueba el pequeño modelo de visión local de Cactus Compute, valida el OCR y la extracción de objetos con datos reales y comprende las...
Cómo programar un agente de programación en Open WebUI en un servidor doméstico
Configura una automatización de agente de programación solo para informes en Open WebUI, selecciona su terminal y espacio de trabajo, y verifica los permisos,...
