“Ho copiato i file via SCP direttamente nella cartella, ma in Nextcloud non si vede niente.” I file ci sono, un ls sul server lo conferma. Solo che Nextcloud non lo sa.
Perché i file sono invisibili
Nextcloud non legge l'intero file system a ogni caricamento di pagina. Tiene invece nel database una cache dei file (tabella filecache, ad esempio oc_filecache a seconda del prefisso) con percorso, dimensione, data di modifica, ETag e permessi di ogni file. Interfaccia web, client di sincronizzazione, condivisioni e ricerca lavorano su queste voci.
Quando un file arriva dall'interfaccia web, da WebDAV o da un client, Nextcloud crea la voce da solo. Se invece viene copiato direttamente nella cartella dati – con SCP, rsync, cp o da un disco montato – la voce manca. Per Nextcloud il file non esiste.
La soluzione: occ files:scan
Il comando files:scan riallinea file system e database. Va eseguito come utente del web server dalla cartella di Nextcloud; su Debian e Ubuntu di solito è www-data:
cd /var/www/nextcloud
sudo -u www-data php occ files:scan --path="utente/files/cartella"Il percorso inizia con l'ID dell'utente, seguito da files e dalla cartella dentro la sua directory. Scansionare solo questo sottoalbero è molto più veloce che scansionare un utente intero.
Altre varianti:
# tutti i file di un utente
sudo -u www-data php occ files:scan utente
# tutti gli utenti (su istanze grandi richiede molto tempo)
sudo -u www-data php occ files:scan --allSe Nextcloud gira nell'immagine Docker ufficiale, il comando si esegue nel container:
docker exec -u www-data nextcloud php occ files:scan --path="utente/files/cartella"Il nome del container può essere diverso a seconda dell'installazione.
Errori tipici
Utente sbagliato. occ deve girare con l'utente proprietario di config/config.php. Se lanciato come root, si interrompe con un messaggio in tal senso. Usare quindi sempre sudo -u www-data (o l'utente del web server in uso).
Proprietario sbagliato. I file copiati appartengono spesso all'utente che li ha copiati, e il web server non riesce a leggerli o modificarli. Prima della scansione correggere:
chown -R www-data:www-data /var/www/nextcloud/data/utente/files/cartellaLa cartella dati non è sempre /var/www/nextcloud/data. Il percorso reale è indicato in config/config.php alla voce datadirectory.
Crittografia. Se la crittografia lato server è attiva, non si possono semplicemente mettere file in chiaro nella cartella dati. L'unica strada è WebDAV o un client.
Hosting gestito. Sulle istanze Nextcloud gestite di solito non c'è accesso shell e quindi nemmeno occ. Lì il caricamento tramite le interfacce ufficiali è comunque l'unica via.
Meglio in futuro: caricare tramite Nextcloud
La soluzione più pulita è non aggirare il server. Così file system e database restano sincronizzati automaticamente, e versioni, condivisioni e notifiche funzionano come previsto.
- Client desktop: mettere i file nella cartella sincronizzata.
- WebDAV: ad esempio con un file manager o con
rclonesuhttps://cloud.esempio.it/remote.php/dav/files/UTENTE/. - Grandi quantità di dati: sempre WebDAV, con uno strumento che gestisca ripetizioni e trasferimenti paralleli.
In config.php esiste l'opzione filesystem_check_changes, con cui Nextcloud controlla le modifiche a ogni accesso. Costa però prestazioni e non è una buona soluzione permanente per copie dirette regolari.
Come verificare
- I file si trovano nel percorso giusto sotto
datadirectory? - Appartengono all'utente del web server?
occ files:scaneseguito come utente del web server con il--pathcorretto?- Letto l'output della scansione (cartelle, file, errori)?
- Ricaricata l'interfaccia web per controllare che tutto sia visibile?
- Previsti WebDAV o il client per i caricamenti futuri?
Chi lavora spesso con Nextcloud trova nel blog anche un articolo sugli errori tipici di SAML e OIDC. La regola di questo caso vale però sempre: Nextcloud mostra ciò che c'è nel suo database – e niente di più.