Installare Jellyfin Server su Ubuntu 24.04 passo dopo passo

Jellyfin su Ubuntu 24.04 conviene installarlo in modo pulito: repository ufficiale, servizio systemd verificabile e accesso esposto solo dove serve. La differenza tra un’installazione che “parte” e una che regge nel tempo sta quasi sempre in tre punti: gestione del repository, permessi sulle librerie media e rete. Qui si parte dal sistema base e si chiude con controlli concreti, senza affidarsi a presupposti fragili.

Prima decisione utile: Jellyfin deve leggere i file multimediali ma non deve diventare proprietario dell’intero storage. Quindi si lavora con un utente dedicato, mount coerenti e permessi minimi. Se il server è dietro reverse proxy o esposto via CDN, quel pezzo va pensato dopo l’avvio locale, non prima. L’obiettivo iniziale è semplice: servizio attivo, interfaccia web raggiungibile in LAN, librerie visibili, niente errori nei log.

Prerequisiti che evitano problemi inutili

Ubuntu 24.04 aggiornato, accesso sudo e una directory media già pronta, ad esempio su un disco secondario o su un NAS montato in locale. Se i contenuti stanno su filesystem esterno, verifica prima che il mount sia stabile al boot. Jellyfin non ama i percorsi che spariscono dopo il riavvio.

Controlla anche lo spazio libero e lo stato della rete, perché un’installazione corretta ma con disco quasi pieno o DNS instabile produce sintomi fuorvianti. Un controllo rapido evita di inseguire falsi positivi più avanti.

Comandi utili di base:

lsb_release -a
hostnamectl
free -h
df -hT
ip a
resolvectl status

Se uno di questi punti è incoerente, sistemalo prima. In particolare, se il disco media non è montato in modo persistente, aggiungi o correggi il relativo record in /etc/fstab e verifica con sudo mount -a. Meglio scoprirlo ora che dopo aver popolato la libreria.

Installazione del repository ufficiale Jellyfin

Su Ubuntu 24.04 la strada più ordinata è il repository ufficiale Jellyfin. Evita pacchetti presi a caso o PPA non mantenuti: per un media server contano aggiornamenti prevedibili e dipendenze coerenti. Il flusso tipico è: installare i prerequisiti, importare la chiave del repository e aggiungere la sorgente APT.

Prima installa gli strumenti necessari:

sudo apt update
sudo apt install -y curl gnupg ca-certificates apt-transport-https

Poi crea il keyring e la sorgente. Il formato con signed-by è preferibile perché limita l’ambito della chiave e riduce la superficie di rischio rispetto a una configurazione globale.

sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://repo.jellyfin.org/jellyfin_team.gpg.key | sudo gpg --dearmor -o /etc/apt/keyrings/jellyfin.gpg
echo "deb [signed-by=/etc/apt/keyrings/jellyfin.gpg] https://repo.jellyfin.org/ubuntu noble main" | sudo tee /etc/apt/sources.list.d/jellyfin.list
sudo apt update

Qui c’è un dettaglio importante: Ubuntu 24.04 usa il codename noble. Se il repository non viene risolto correttamente, il primo sospetto non è Jellyfin ma la riga APT o la chiave. La verifica minima è apt update senza errori di firma o di release.

Installa il server:

sudo apt install -y jellyfin

Al termine, il pacchetto crea il servizio systemd e l’utente di esecuzione dedicato. Non toccare subito i permessi globali: prima controlla che il servizio sia effettivamente installato e avviabile.

Avvio del servizio e verifica del socket HTTP

Il servizio parte in ascolto sulla porta 8096 in HTTP. Per la prima verifica non serve ancora TLS: serve capire se il demone è vivo e se risponde localmente. Questo separa i problemi applicativi dai problemi di rete esterna.

sudo systemctl enable --now jellyfin
systemctl status jellyfin --no-pager
ss -ltnp | grep 8096
curl -I http://127.0.0.1:8096

Il risultato atteso è active (running), una socket in ascolto su 0.0.0.0:8096 o 127.0.0.1:8096 a seconda della configurazione, e una risposta HTTP con status 200 o 302. Se ottieni connection refused, controlla prima il log del servizio:

journalctl -u jellyfin -n 100 --no-pager

Gli errori più comuni in questa fase sono database iniziale non creato, directory non scrivibili o conflitti di porta. In un’installazione pulita, Jellyfin crea la sua struttura sotto la home di servizio e sotto /var/lib/jellyfin o percorsi equivalenti gestiti dal pacchetto.

Primo accesso alla web UI

Dalla LAN apri http://IP_DEL_SERVER:8096. Il wizard iniziale guida nella creazione dell’utente amministratore, nella lingua e nelle librerie. Non saltare la parte sugli utenti: l’account admin iniziale è il punto di controllo dell’intera installazione.

Se la pagina non si apre dall’esterno ma funziona in locale, la differenza è quasi sempre firewall o binding. Su Ubuntu, se usi UFW, la regola minima è aprire la porta 8096 solo dove serve. Se il server è in rete fidata, puoi limitare il traffico alla subnet LAN invece di esporre tutto.

sudo ufw allow from 192.168.1.0/24 to any port 8096 proto tcp
sudo ufw status verbose

Se non usi UFW, verifica l’eventuale firewall a monte: router, security group cloud o ACL del firewall dedicato. L’errore classico è vedere il servizio in ascolto e concludere che il problema sia Jellyfin, quando in realtà il pacchetto è sano ma la rete blocca il traffico.

Configurare le librerie media senza rompere i permessi

La parte che crea più attrito non è il server, ma il filesystem. Jellyfin deve leggere film, serie e musica senza dover diventare proprietario dei file originali. Il modo più pulito è far sì che l’utente del servizio abbia accesso in lettura, eventualmente in scrittura solo alle directory che devono ospitare metadati o upload locali.

Individua l’utente del servizio e il gruppo che ha accesso ai media. In molti casi conviene creare un gruppo dedicato, aggiungere l’utente Jellyfin e assegnare al contenuto i permessi di gruppo corretti. In alternativa, se i media arrivano da un NAS con ACL o da un mount NFS, il controllo va fatto lì, non sul server Jellyfin.

id jellyfin
ls -ld /srv/media /srv/media/films /srv/media/series

Un esempio pragmatico, da adattare al tuo layout, è questo:

sudo groupadd media
sudo usermod -aG media jellyfin
sudo chgrp -R media /srv/media
sudo chmod -R 2750 /srv/media

Il bit 2 sul permesso directory mantiene l’eredità del gruppo nei nuovi file. È utile se più processi condividono la stessa tree. Non usare chmod -R 777: risolve in fretta e apre problemi di sicurezza e di manutenzione. Se i file sono già distribuiti con owner diversi, meglio intervenire con ACL mirate o con un processo di ingest dedicato.

Se vuoi verificare l’accesso reale prima di creare le librerie, puoi testare con un comando eseguito come utente Jellyfin:

sudo -u jellyfin test -r /srv/media/films && echo OK || echo KO

Se il test fallisce, il problema è quasi sempre nei permessi del mount, nelle ACL o nel mapping UID/GID nel caso di NFS o container. Non cambiare a caso ownership dell’intero storage: prima identifica il punto di rottura.

Se il media storage è su NAS o disco esterno

Qui si vede spesso la differenza tra un sistema stabile e uno che si degrada nel tempo. Se il contenuto è su NAS, meglio un mount persistente con opzioni esplicite che un collegamento temporaneo creato a mano. L’obiettivo è che, dopo ogni reboot, Jellyfin trovi gli stessi percorsi senza interventi manuali.

Per un mount locale o di rete, verifica che il filesystem sia disponibile prima dell’avvio del servizio. In /etc/fstab puoi usare opzioni coerenti con il tuo caso; per NFS, ad esempio, conviene evitare timeout troppo aggressivi e definire una strategia chiara di fallback. Se il mount non c’è, Jellyfin può avviarsi lo stesso ma le librerie risulteranno vuote o con errori di scansione.

Verifica il mount con:

mount | grep /srv/media
systemctl status remote-fs.target --no-pager

Se vuoi che Jellyfin aspetti il mount, aggiungi una dipendenza systemd drop-in invece di forzare hack all’avvio. È una modifica reversibile e più leggibile. Un esempio minimale è creare un override che richieda il mount target relativo, ma solo se il tuo layout è davvero statico.

Hardening minimo sensato

Jellyfin non ha bisogno di essere esposto su Internet in chiaro. Se devi pubblicarlo, la scelta più pulita è reverse proxy con TLS terminato davanti, accesso ristretto e aggiornamenti regolari. In LAN basta spesso la porta 8096 su subnet fidata, senza ulteriori strati. L’hardening non deve complicare la manutenzione più del necessario.

Misure minime utili:

• limitare l’accesso alla porta 8096 alla LAN o al proxy;
• usare account amministratore separato da quello quotidiano;
• mantenere aggiornato il pacchetto con il normale ciclo APT;
• evitare percorsi media scrivibili da utenti non necessari;
• se esposto pubblicamente, mettere TLS davanti e non direttamente sul demone.

Se usi un reverse proxy come Nginx, il mapping base è semplice: il proxy parla con 127.0.0.1:8096 e pubblica il servizio in HTTPS. In quel caso, Jellyfin resta interno e la superficie d’attacco si sposta sul proxy, che è più adatto a gestire certificati, header e policy di accesso.

Un controllo rapido della versione installata e dei pacchetti aggiornabili aiuta a non dimenticare il ciclo di patching:

apt-cache policy jellyfin
apt list --upgradable | grep jellyfin

Verifica finale della libreria e della riproduzione

La configurazione non è completa finché non hai verificato almeno tre cose: la libreria viene indicizzata, i file sono leggibili e un contenuto si riproduce davvero. Il test della UI da solo non basta, perché può aprirsi anche con librerie vuote o con permessi parziali.

Dopo aver aggiunto una libreria, controlla i log durante la scansione. Se qualcosa non torna, Jellyfin di solito lo segnala in modo abbastanza chiaro: file non accessibili, formato non supportato, directory vuota o permessi insufficienti.

journalctl -u jellyfin -f

Se la scansione non parte o si interrompe, torna ai permessi e al mount. Se parte ma non trova media, verifica il path esatto inserito nel wizard. Un errore banale come un punto di mount diverso da quello atteso produce una libreria apparentemente “rotta”, ma in realtà stai indicando la directory sbagliata.

Per una verifica funzionale minima, apri un file video noto, controlla che la transcodifica non saturi subito CPU e RAM e osserva i tempi di risposta. Su macchine piccole, la differenza tra playback diretto e transcodifica hardware è enorme. Se hai GPU o iGPU supportata, la configurazione dell’accelerazione va affrontata dopo che il sistema base è stabile, non prima.

Problemi tipici e come leggerli senza perdere tempo

Se la web UI non risponde ma il servizio è attivo, il primo filtro è sempre ss -ltnp e un curl locale. Se il servizio non ascolta, vai sui log. Se ascolta in locale ma non da remoto, guarda firewall e NAT. Se la UI si apre ma le librerie sono vuote, il problema è quasi sempre permessi o path errato. Se la riproduzione fallisce solo su alcuni file, il tema può essere codec, transcodifica o storage lento.

Questo approccio evita di fare modifiche a cascata. Prima si identifica il layer giusto, poi si interviene con il minimo cambiamento reversibile. In pratica: osservazione, verifica, correzione mirata.

Aggiornamenti e manutenzione ordinaria

Con Jellyfin in produzione domestica o small office, gli aggiornamenti vanno gestiti con la stessa disciplina di un servizio pubblico: snapshot o backup prima del cambio, upgrade in finestra tranquilla, controllo post-update. Il pacchetto APT rende il processo semplice, ma non elimina la necessità di verificare che la nuova versione legga ancora correttamente database e librerie.

sudo apt update
sudo apt upgrade -y
systemctl status jellyfin --no-pager
journalctl -u jellyfin -n 50 --no-pager

Se fai backup, includi almeno la configurazione applicativa e i metadati, oltre ai media stessi se non sono già protetti altrove. Il punto non è salvare solo i file video: la parte che richiede più tempo da ricostruire sono utenti, librerie, impostazioni e poster cache.

In un’installazione ben tenuta, la manutenzione ordinaria è noiosa. Ed è un buon segno: significa che il servizio è stato impostato con scelte semplici, verificabili e facili da ripristinare.