1 13/10/2026 10 min

Installare Pydio oggi: la scelta giusta è partire dall’ambiente, non dal pacchetto

Pydio non si installa bene se si salta un passaggio preliminare: prima si definisce il contesto operativo, poi si prepara il web server, infine si completa la configurazione dell’applicazione. Su Windows 10 l’approccio più pratico è usare un ambiente locale con Apache, PHP e database; su Ubuntu 19.04 il percorso è più lineare perché i componenti server sono nativi e si controllano meglio permessi, servizi e log. In entrambi i casi l’obiettivo è lo stesso: avere un file sharing web affidabile, con PHP correttamente eseguito e storage persistente.

Qui tratto l’installazione in modo operativo, con una logica da sysadmin: prerequisiti verificabili, configurazione minima reversibile, controllo dei log e verifica finale del servizio. Dove i dettagli possono cambiare in base alla versione di Pydio, lo segnalo esplicitamente: è il modo corretto per evitare di incollare una procedura sbagliata su una release diversa.

Prerequisiti comuni: PHP, database, web server e directory dati

Pydio richiede un web server che serva PHP in modo corretto, un database per i metadati e una directory dati separata dalla root web. Questa separazione non è cosmetica: serve per non esporre file utente e per poter fare backup coerenti. La prima verifica, quindi, non è la GUI dell’applicazione, ma la presenza dei componenti base.

Se lavori su Windows 10, la strada più semplice è usare un pacchetto integrato tipo XAMPP o WampServer. Su Ubuntu 19.04 puoi usare Apache, PHP e MariaDB installati dai repository. In entrambi i casi controlla la versione PHP richiesta dalla release di Pydio che vuoi usare: è il punto che rompe più spesso le installazioni fatte “a memoria”. Se la documentazione della tua versione non è disponibile, fermati e verifica sul sito del progetto o nella release notes prima di procedere.

Installazione su Windows 10 con stack locale

Su Windows 10 l’installazione ha senso in tre scenari: test in locale, demo interna o piccola istanza non esposta direttamente su internet. Se l’obiettivo è produzione, il server Linux resta la scelta più sensata per controllo dei permessi, automazione e manutenzione. Qui assumo un’installazione locale con Apache, PHP e MariaDB già disponibili tramite XAMPP; il ragionamento è simile con altri stack, ma i percorsi dei file cambiano.

  1. Scarica l’archivio di Pydio dalla pagina ufficiale della release che vuoi usare. Evita mirror casuali: per una piattaforma che gestisce documenti, integrità del pacchetto e provenienza contano più della comodità.
  2. Estrai i file dentro la directory del server web, per esempio C:\xampp\htdocs\pydio. Se usi un virtual host dedicato, preferisci una cartella separata invece di appoggiarti alla root generica.
  3. Verifica che PHP sia attivo aprendo una pagina di test con phpinfo() o controllando la schermata di stato del pannello XAMPP. Se PHP non è eseguito dal web server, Pydio non partirà correttamente.
  4. Crea un database dedicato, per esempio pydio, e un utente con privilegi limitati su quel solo database. Non usare account amministrativi generici: riduci il blast radius in caso di credenziali esposte.
  5. Imposta una directory dati fuori dalla cartella pubblica, ad esempio C:\pydio-data, e verifica che l’utente del servizio web abbia permessi di lettura e scrittura.
  6. Apri il browser e completa il wizard iniziale di Pydio indicando database, percorso dati e credenziali amministrative dell’applicazione.

Se il wizard si ferma su una pagina bianca o su un errore generico, il primo controllo non è “ricaricare la pagina”, ma leggere i log di Apache e PHP. Su XAMPP il punto tipico è C:\xampp\apache\logs\error.log; se il problema è PHP, spesso il messaggio è già lì, con estensione mancante, sintassi errata o versione non compatibile.

Esempio di check rapido lato browser: se la home dell’istanza restituisce HTTP 500, prima verifica il log e poi testa un file PHP minimo. Un controllo banale ma efficace è questo:

<?php phpinfo();

Se questo file non viene interpretato come PHP, il problema non è Pydio: è lo stack web. In quel caso correggi associazione PHP/Apache o la configurazione del modulo FastCGI prima di toccare l’applicazione.

Installazione su Ubuntu 19.04 con Apache, PHP e MariaDB

Su Ubuntu 19.04 l’installazione è più prevedibile, ma va tenuto presente che la release è fuori dal ciclo di supporto standard: in un contesto reale questo dettaglio pesa, perché repository e pacchetti possono risultare vecchi o non più mantenuti. Se stai leggendo oggi questa procedura per un server attuale, la lezione è semplice: usa una release supportata. Se sei vincolato a 19.04, congela il perimetro, documenta le versioni e non improvvisare upgrade sparsi.

  1. Aggiorna l’indice pacchetti e installa il necessario:
sudo apt update
sudo apt install apache2 mariadb-server php libapache2-mod-php php-mysql php-xml php-mbstring php-curl php-zip php-gd unzip

Il set di estensioni può cambiare in base alla versione di Pydio: se il setup segnala una libreria mancante, installa solo quella richiesta e ripeti il controllo. Non aggiungere moduli a caso: più dipendenze significa più superficie di manutenzione.

  1. Abilita e avvia i servizi base:
sudo systemctl enable --now apache2 mariadb
  1. Prepara il database e l’utente applicativo:
sudo mysql
CREATE DATABASE pydio CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'pydiouser'@'localhost' IDENTIFIED BY 'una_password_forte';
GRANT ALL PRIVILEGES ON pydio.* TO 'pydiouser'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Qui c’è un punto importante: la password nel comando sopra è un esempio, non va copiata in chiaro in documentazione operativa né riutilizzata in ambienti reali. In produzione ruota la credenziale al termine del setup e conserva il segreto in un password manager o in un vault.

  1. Scarica e posiziona Pydio nella directory web, per esempio /var/www/pydio, poi assegna ownership corretta:
sudo mkdir -p /var/www/pydio
sudo chown -R www-data:www-data /var/www/pydio
  1. Crea una directory dati fuori dal web root, ad esempio /srv/pydio-data, e assegna i permessi al solo utente del server web:
sudo mkdir -p /srv/pydio-data
sudo chown -R www-data:www-data /srv/pydio-data
sudo chmod 750 /srv/pydio-data

Se usi un virtual host, definiscilo prima di lanciare il setup. Un esempio minimale, da adattare alla tua versione di Apache, è questo:

<VirtualHost *:80> ServerName pydio.local DocumentRoot /var/www/pydio <Directory /var/www/pydio> AllowOverride All Require all granted </Directory>
</VirtualHost>

Dopo aver abilitato il sito, ricarica Apache e verifica la sintassi:

sudo apache2ctl configtest
sudo systemctl reload apache2

Se il controllo restituisce Syntax OK, la parte web è coerente. Se invece trovi un errore, correggi prima il virtual host: è più veloce che inseguire sintomi dall’interfaccia di Pydio.

Configurazione iniziale nell’interfaccia di Pydio

Quando apri l’URL dell’istanza per la prima volta, il wizard chiede i parametri dell’applicazione. Qui l’errore classico è confondere il database dell’app con il percorso dati. Il database contiene configurazione, utenti e metadati; la directory dati conserva i contenuti reali. Tenerli separati facilita backup e ripristino.

  1. Inserisci i dati di connessione al database creato in precedenza.
  2. Indica il percorso della directory dati esterna al web root.
  3. Crea l’account amministrativo iniziale dell’applicazione.
  4. Verifica che il wizard completi la fase di inizializzazione senza warning critici.

Se il setup segnala problemi di scrittura, controlla subito tre punti: ownership della cartella dati, permessi della directory temporanea PHP e modulo mancante. Il file system è spesso la causa reale anche quando il messaggio a schermo sembra generico.

Su Ubuntu puoi controllare i log con:

sudo tail -n 50 /var/log/apache2/error.log
sudo journalctl -u apache2 -n 50 --no-pager

Su Windows, se usi XAMPP, i log utili sono quelli di Apache e PHP. Se il browser restituisce una pagina bianca, il log applicativo non basta: devi guardare la console del server web.

Permessi, storage e backup: la parte che evita i ripristini dolorosi

La differenza tra una demo e una installazione gestibile sta quasi sempre nei permessi e nel backup. Pydio può funzionare anche con diritti larghi, ma è una cattiva idea: l’applicazione deve scrivere dove serve e basta. Se il servizio web ha accesso eccessivo al file system, qualsiasi compromissione dell’applicazione diventa più grave.

La regola pratica è questa: il contenuto utente in una directory dedicata, il database in un backup separato, la configurazione esportata o versionata. In caso di errore, il ripristino più pulito è spesso quello che ricrea il database e reimporta i dati, non quello che tenta di “riparare” file sparsi.

Per un minimo di igiene operativa, su Ubuntu salva almeno questi elementi:

  • dump del database Pydio;
  • directory dati esterna;
  • configurazione del virtual host Apache;
  • eventuali file di configurazione PHP personalizzati.

Per il dump del database, un comando essenziale è questo:

mysqldump -u pydiouser -p pydio > pydio.sql

Conserva il file in un percorso sicuro e non lasciare credenziali o dump accessibili a utenti non autorizzati. Se il backup contiene dati sensibili, cifra il repository o il supporto di destinazione.

Verifiche tecniche dopo l’installazione

Una installazione non è “finita” quando compare la schermata iniziale. È finita quando hai verificato che l’app risponde, scrive nella directory dati, salva nel database e riapre la sessione dopo un reload del servizio. La sequenza minima di controllo è questa.

  1. Apri l’interfaccia web e autentica l’utente amministrativo.
  2. Carica un file di test e verifica che compaia nella directory dati prevista.
  3. Riavvia il servizio web e controlla che l’accesso resti valido.
  4. Controlla i log per warning ripetuti o errori di permessi.
  5. Esegui un backup di prova e verifica che il file prodotto sia leggibile.

Su Ubuntu, il controllo del servizio è immediato:

systemctl status apache2
systemctl status mariadb

Se uno dei due servizi non è attivo, l’interfaccia di Pydio può sembrare regolare per qualche minuto e poi degradare al primo accesso al database o al primo upload. Non fermarti alla home page: fai un’azione reale sull’applicazione.

Problemi frequenti e come leggerli senza perdere tempo

Il problema più comune è la incompatibilità PHP. Se il progetto richiede un set specifico di estensioni e il server ne ha di meno, il setup si interrompe o alcune funzioni spariscono. Il secondo problema è la directory dati non scrivibile. Il terzo, soprattutto su Windows, è la confusione tra document root, path fisico e permessi effettivi del processo Apache.

Un errore utile da tenere a mente: se il browser mostra un 403, il problema è spesso il virtual host o i permessi del path; se mostra un 500, il problema è quasi sempre lato PHP o configurazione web; se il login funziona ma il file upload fallisce, guarda quota disco, permessi e upload_max_filesize in PHP.

La verifica più rapida resta sempre la stessa: log del web server, log PHP, stato del database e permessi della directory dati. Se questi quattro elementi sono coerenti, il resto è quasi sempre un dettaglio di configurazione.

Scelta architetturale: Windows 10 per laboratorio, Ubuntu per servizio stabile

Se devi solo testare Pydio o fare una demo locale, Windows 10 va bene e ti fa risparmiare tempo. Se invece il servizio deve restare attivo, ricevere upload, gestire utenti e produrre audit minimali, Ubuntu è una base più pulita. Il motivo non è ideologico: è operativo. Su Linux hai meno attrito nel controllo dei servizi, nei permessi e nella diagnostica.

In pratica: Windows 10 per prova e validazione funzionale; Ubuntu 19.04 solo se sei vincolato a quella versione e consapevole del ciclo di supporto; altrimenti una release LTS supportata è la scelta corretta. La procedura di installazione resta concettualmente la stessa, ma la manutenzione cambia parecchio.

Se vuoi, posso trasformare questa guida in una procedura più specifica per una singola release di Pydio, oppure adattarla a XAMPP su Windows o ad Apache/Nginx su Ubuntu con configurazione completa del virtual host.