Installare Seafile Server su WSL in Windows 10

Installare Seafile Server su WSL in Windows 10 ha senso solo se accetti un compromesso preciso: ambiente Linux comodo per test, laboratorio o uso personale, ma non una piattaforma che io considererei robusta quanto una VM o un host Linux nativo. Il punto critico non è Seafile in sé, ma il contesto: WSL cambia il comportamento di rete, storage, avvio dei servizi e persistenza dei processi. Se parti con questa consapevolezza, eviti metà dei problemi tipici.

Qui l’obiettivo è arrivare a un’installazione funzionante, con MariaDB, Python e dipendenze minime, più una strategia sensata per esporre il servizio da Windows e tenerlo in vita dopo il logout. Dove WSL introduce limiti, li segnalo subito e ti dico come verificarli con comandi concreti. Non ha senso promettere un setup “production-grade” dentro WSL: dipende troppo dalla versione di Windows, dalla distro Linux scelta e dal modo in cui vuoi gestire rete e backup.

Scelta architetturale: WSL1 o WSL2, e perché qui conta

Per Seafile su Windows 10, WSL2 è la scelta corretta nella maggior parte dei casi. WSL1 è più “integrato” con il filesystem Windows, ma ha limiti più fastidiosi per software server moderno. WSL2 introduce un vero kernel Linux e un layer di virtualizzazione leggero: in cambio ottieni un comportamento più vicino a Linux reale, ma con una rete NAT e alcune attenzioni in più per l’accesso dall’esterno.

Le conseguenze pratiche sono tre:

• i servizi lanciati in WSL2 non sono automaticamente “pubblici” su tutte le interfacce di Windows;
• l’IP della distro può cambiare al riavvio;
• i file su filesystem Windows funzionano, ma spesso sono più lenti e meno affidabili per carichi intensivi rispetto al filesystem interno Linux.

Per Seafile conviene tenere dati, database e log nel filesystem Linux di WSL, non sotto `/mnt/c/...`. Seafile fa molte operazioni su metadati e piccoli file: metterlo su NTFS montato in WSL è una scelta che paghi in latenza e, in certi casi, in comportamento poco prevedibile.

Prerequisiti minimi e verifica dello stato del sistema

Prima di installare, verifica di avere una distro WSL2 aggiornata e abbastanza spazio disco libero. Seafile non è enorme, ma tra repository, database e cache puoi saturare facilmente una partizione piccola.

Controlli utili da Windows PowerShell:

wsl -l -v
wsl --status

Ti interessa vedere la distro con Version 2. Se non lo è, convertila con attenzione, perché il passaggio cambia il backend di storage e rete:

wsl --set-version Ubuntu-22.04 2

Dentro la distro Linux, aggiorna il sistema e installa gli strumenti base:

sudo apt update
sudo apt -y upgrade
sudo apt -y install curl wget ca-certificates gnupg lsb-release unzip tar vim net-tools openssl

Se vuoi ridurre i problemi di avvio, imposta anche un hostname leggibile e controlla la versione della distro. Non è fondamentale, ma quando poi guardi log e processi aiuta.

Dipendenze di Seafile: database, runtime e librerie

Seafile Server richiede un database relazionale. In questo scenario la scelta più semplice è MariaDB. Puoi usare MySQL compatibile, ma MariaDB è la strada più lineare su Ubuntu/Debian in WSL. Seafile usa anche componenti Python e librerie di sistema; la versione esatta dipende dal pacchetto Seafile che scarichi, ma il principio resta lo stesso: prepara una base pulita, non un sistema già sporco di pacchetti non necessari.

Installazione base di MariaDB e strumenti utili:

sudo apt -y install mariadb-server mariadb-client python3 python3-pip python3-venv libmariadb-dev libmysqlclient-dev libffi-dev libssl-dev

Avvia e verifica il servizio:

sudo systemctl enable mariadb
sudo systemctl start mariadb
sudo systemctl status mariadb --no-pager

Se `systemctl` non funziona nella tua build di WSL, il problema non è Seafile: è l’integrazione del tuo ambiente WSL. In quel caso devi prima abilitare il supporto ai servizi oppure usare un meccanismo alternativo di avvio. La verifica minima è semplice: il comando deve restituire uno stato coerente e non un errore di init system mancante.

Preparazione del database e utente dedicato

Non usare root per Seafile. Crea un database dedicato e un utente con privilegi limitati. È la base minima di igiene operativa, anche in un laboratorio.

sudo mysql

CREATE DATABASE ccnet_db CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
CREATE DATABASE seafile_db CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
CREATE DATABASE seahub_db CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
CREATE USER 'seafile'@'localhost' IDENTIFIED BY 'PASSWORD_FORTE_E_RINNOVATA';
GRANT ALL PRIVILEGES ON ccnet_db.* TO 'seafile'@'localhost';
GRANT ALL PRIVILEGES ON seafile_db.* TO 'seafile'@'localhost';
GRANT ALL PRIVILEGES ON seahub_db.* TO 'seafile'@'localhost';
FLUSH PRIVILEGES;
EXIT;

La password va trattata come segreto: non metterla in chiaro in note condivise, non salvarla in un file world-readable. Se devi documentarla per uso interno, usa un vault o almeno un file con permessi stretti. La verifica minima è controllare che l’utente esista e che i database siano stati creati:

mysql -u seafile -p -e "SHOW DATABASES;"

Download e posizionamento dei file Seafile

Scarica il pacchetto server dal sito ufficiale di Seafile e posizionalo nel filesystem Linux della distro, ad esempio sotto `/opt/seafile`. Evita directory su drive Windows montati in WSL. La differenza, nelle operazioni reali, si sente soprattutto quando il sistema comincia a gestire sincronizzazioni e metadata.

sudo mkdir -p /opt/seafile
cd /tmp
wget https://download.seafile.com/published/seafile-server_x.y.z_x86-64.tar.gz
sudo tar -xzf seafile-server_x.y.z_x86-64.tar.gz -C /opt/seafile --strip-components=1

Il nome del file cambia con la versione. Non forzare il comando se il pacchetto non coincide: verifica il nome preciso e l’hash pubblicato dal vendor. Se hai dubbi, il controllo più banale è:

ls -lh /opt/seafile

Configurazione iniziale di Seafile

Dentro la directory estratta trovi lo script di setup. È qui che definisci host, porte, database e directory dati. In WSL, il punto più delicato è l’endpoint di rete: se vuoi accedere da altre macchine della LAN, non basta sapere che il servizio ascolta su `127.0.0.1`. Devi decidere se tenere l’accesso locale, aprire il port forwarding da Windows o esporre il servizio in modo controllato.

cd /opt/seafile
sudo ./setup-seafile-mysql.sh

Durante il setup ti verranno richiesti parametri come hostname, porta web e credenziali database. Se vuoi un setup semplice, mantieni porte standard e fai puntare il server a un nome che risolva correttamente da Windows e, se necessario, dalla rete. Se l’accesso resta locale, `localhost` basta. Se vuoi pubblicarlo in LAN, pianifica il NAT di WSL2 e il firewall Windows prima di andare oltre.

Un controllo utile dopo il setup è verificare che i file di configurazione siano stati generati e che i percorsi puntino al posto giusto. Cerca ad esempio `ccnet.conf`, `seafile.conf` e `seahub_settings.py` nella directory di installazione o sotto la directory dati indicata dal wizard.

Avvio dei servizi e verifica del binding di rete

Seafile di solito parte con script dedicati per backend e interfaccia web. L’ordine conta: prima il database, poi i servizi Seafile, infine Seahub. Se qualcosa fallisce, il log ti dice subito dove si è rotto il flusso.

cd /opt/seafile
sudo ./seafile.sh start
sudo ./seahub.sh start

Controlla i processi e le porte in ascolto:

ps -ef | grep -E 'seafile|seahub' | grep -v grep
ss -ltnp | grep -E '8000|8082|8080'

Le porte precise possono variare a seconda della versione e della configurazione. Quello che ti interessa è che il servizio ascolti dove ti aspetti e che non ci siano conflitti con altri demoni già presenti in Windows o in WSL. Se il browser non apre la pagina, fai un test locale dalla distro:

curl -I http://127.0.0.1:8000

Se la risposta è un redirect o un `200/302`, il servizio base è vivo. Se ottieni `connection refused`, il problema è quasi sempre uno di questi: servizio non partito, porta diversa, crash all’avvio, o binding su un indirizzo non raggiungibile dal punto da cui stai testando.

Accesso da Windows e pubblicazione sulla rete

Dal lato Windows, l’accesso a `localhost` verso WSL2 spesso funziona, ma non dare per scontato che basti per tutti gli scenari. Se vuoi raggiungere Seafile da altri dispositivi, di solito devi combinare tre cose: ascolto corretto in WSL, regole firewall Windows e port forwarding o proxy verso l’IP della distro.

Per sapere l’IP della distro WSL2:

hostname -I

Da Windows puoi poi verificare la raggiungibilità sulla porta scelta con:

Test-NetConnection 127.0.0.1 -Port 8000

Se devi esporre il servizio oltre il PC locale, la parte più pulita è far passare il traffico attraverso un reverse proxy in Windows o un port proxy stabile, con regole firewall esplicite. Il punto non è “aprire la porta” e basta: devi sapere chi può raggiungerla, da dove e con quale livello di autenticazione. In un ambiente WSL domestico o da laboratorio, questo significa almeno limitare la sorgente e non pubblicare nulla su Internet senza un ragionamento serio su TLS, aggiornamenti e hardening.

Avvio automatico e persistenza tra riavvii

WSL non nasce come init system classico per servizi persistenti. Se vuoi che Seafile riparta da solo, hai due strade: usare la capacità di avvio dei servizi nella distro, se disponibile, oppure creare un wrapper lato Windows che rilanci la distro e avvii gli script. Per un uso serio, la seconda opzione è più controllabile, ma anche più fragile da mantenere.

La verifica minima è semplice: riavvia Windows, poi controlla se i processi sono vivi e se la porta risponde. Se non lo sono, non inseguire subito Seafile: prima risolvi il meccanismo di startup della distro.

ps -ef | grep seahub
curl -I http://127.0.0.1:8000

Se preferisci una soluzione più prevedibile, valuta l’esecuzione in una VM Linux o in un piccolo server dedicato. È spesso meno elegante di WSL, ma molto più lineare per backup, servizi e networking.

TLS, nome host e reverse proxy

Seafile senza TLS ha senso solo in un ambiente davvero chiuso. Anche in LAN, appena i dati attraversano un segmento condiviso o un Wi-Fi non completamente fidato, il discorso cambia. In WSL puoi terminare TLS fuori dalla distro, ad esempio con un reverse proxy Windows o con un proxy Linux davanti a Seafile. L’importante è avere un nome host coerente e un certificato valido per quel nome.

Se usi un reverse proxy, il backend Seafile deve essere raggiungibile in modo affidabile solo dal proxy. Questo riduce la superficie esposta e rende più semplice il rinnovo dei certificati. La verifica minima è osservare la catena completa: browser → proxy → Seafile. Se il browser vede errore TLS ma il backend risponde in locale, il problema è nel proxy; se il proxy non raggiunge il backend, il problema è nel binding o nel forwarding WSL.

Backup: cosa salvare davvero

Un backup sensato di Seafile non è solo la cartella dati. Devi salvare almeno: database MariaDB, directory di configurazione, directory repository e, se usi TLS locale, anche i riferimenti al proxy o i certificati. In WSL il rischio classico è fare copie manuali senza coerenza tra database e file. Se devi fermare il servizio per un dump consistente, fallo in modo esplicito e documentato.

mysqldump -u seafile -p --databases ccnet_db seafile_db seahub_db > /backup/seafile-db.sql
sudo tar -czf /backup/seafile-data.tgz /opt/seafile /path/to/seafile-data

Il percorso reale dei dati dipende dal setup scelto. Non indovinarlo: leggilo nei file di configurazione generati dal wizard. La regola pratica è questa: prima identifichi dove stanno i dati, poi automatizzi il backup, poi testi il restore su un ambiente separato.

Troubleshooting rapido: i guasti più comuni

Se il sito non si apre, in ordine controlla layer e sintomo. Primo: `curl -I` sulla porta locale in WSL. Secondo: `ss -ltnp` per capire se il processo ascolta. Terzo: log di Seafile e MariaDB. Quarto: accesso da Windows con `Test-NetConnection`. Questo ordine evita di perdere tempo su DNS o proxy quando il problema è banalmente un servizio morto.

Log utili da cercare, a seconda del layout della tua installazione:

• log di Seafile nella directory di installazione o nella directory dati indicata dal setup;
• log di Seahub per errori Python, template o database;
• log di MariaDB, se il setup fallisce nella fase iniziale;
• eventuali log di reverse proxy o firewall sul lato Windows.

Due segnali da non ignorare: errori di permessi sulle directory e crash dovuti a dipendenze mancanti. Nel primo caso il fix è quasi sempre correggere ownership e mode delle directory dati; nel secondo, installare la libreria mancante o allineare la versione del pacchetto Seafile con la tua distro. Non fare tentativi ciechi: un `journalctl` o il log applicativo ti dicono subito dove intervenire.

Quando WSL non è la scelta giusta

WSL va bene se vuoi sperimentare, fare demo, tenere un archivio personale o costruire un ambiente di test rapido. Diventa una scelta debole quando hai bisogno di uptime, backup rigorosi, networking stabile, aggiornamenti controllati e restore testato. Seafile è un servizio che vive di file, database e accesso remoto: tutte cose che beneficiano di una piattaforma prevedibile.

Se il tuo obiettivo è un servizio affidabile per più utenti, la scorciatoia giusta spesso non è “ottimizzare WSL”, ma spostare Seafile su una VM Linux o su un piccolo server dedicato. WSL resta utile come banco prova. Per produzione, la fisica del sistema conta più della comodità del laptop.

Assunzione operativa: i comandi e i percorsi indicati vanno adattati alla versione di Seafile e alla distro Linux installata; prima di mettere in esercizio, verifica sempre i file generati dal setup e i log effettivi della tua installazione.