Un caricamento su ownCloud che raggiunge il 99% e poi sembra bloccarsi di solito non si risolve riavviando ripetutamente il caricamento. A quel punto, il browser potrebbe aver già trasferito la maggior parte o la totalità del file mentre il server sta ancora completando operazioni come la ricezione dell'ultimo blocco, l'assemblaggio dei blocchi, lo spostamento del file completato nella sua destinazione, l'aggiornamento dei metadati o il rilascio dei blocchi. La sola percentuale non identifica la causa, quindi l'approccio più rapido è quello di controllare le prove lato server in un ordine prestabilito.
Questa guida utilizza la documentazione di amministrazione di ownCloud Server 11.0 disponibile a ottobre 2026. Gli stessi concetti si applicano a molte implementazioni di ownCloud Classic, ma i percorsi di configurazione e il comportamento di Docker possono differire nelle versioni precedenti. Prima di modificare i limiti, verificare la versione installata e il metodo di implementazione.
| Cosa controllare | Perché è importante | Indizio forte |
|---|---|---|
| log di ownCloud, PHP e del server web | L'errore potrebbe verificarsi dopo che il browser ha terminato l'invio dei dati. | Timeout, problemi di archiviazione, WebDAV, blocco, errore 5xx o errore di autorizzazione durante il caricamento. |
| Spazio libero temporaneo e nella directory di caricamento | I caricamenti suddivisi in blocchi necessitano di spazio di archiviazione temporaneo prima della finalizzazione. | I file di grandi dimensioni non vengono elaborati correttamente, mentre quelli di piccole dimensioni sì, oppure il file system è quasi pieno. |
| Quota utente e spazio di archiviazione di destinazione | Il file finale necessita ancora di spazio nella sua destinazione. | L'errore si verifica solo per un utente, una cartella o una destinazione di archiviazione esterna. |
| Limiti di caricamento e tempo per PHP | Le richieste non suddivise in blocchi e le richieste di supporto possono essere rifiutate o scadere per timeout. | Gli errori possono riguardare le dimensioni della richiesta, il tempo di esecuzione, il tempo di input o i file caricati temporaneamente. |
| durata della sessione | Una sessione che scade prima del completamento di un caricamento di lunga durata può interromperne il completamento. | I problemi riscontrati sono correlati alla durata del caricamento piuttosto che al tipo di file. |
| Proxy inverso, CDN o bilanciatore di carico | Un componente a monte può imporre un proprio limite di dimensione del corpo o di timeout. | L'accesso diretto funziona, ma il nome host pubblico tramite proxy non funziona. |
| Blocco dei file transazionali | ownCloud blocca i file durante l'esecuzione delle operazioni sui file. | I log contengono errori di blocco, soprattutto sotto carico o su sistemi di archiviazione clusterizzati. |
Esegui un caricamento controllato con un file che riproduca in modo affidabile il problema e annota l'ora esatta. Quindi esamina il log di ownCloud, il log di PHP e il log degli errori del server web intorno a quell'orario. Non apportare prima diverse modifiche alla configurazione; in questo modo sarà più difficile capire quale livello ha effettivamente causato l'errore.
La documentazione ufficiale di ownCloud per la risoluzione dei problemi raccomanda esplicitamente di controllare prima i log di PHP, Apache e ownCloud. Nella distribuzione Docker standard, ownCloud documenta che l'output di Apache e PHP viene instradato tramite stdout/stderr del container e suggerisce di seguire i log del container con docker compose logs owncloud -f.
È possibile ottenere il registro di ownCloud anche dall'interfaccia di amministrazione. Il registro di ownCloud e la guida alla configurazione documentano il percorso attraverso Impostazioni > Amministrazione > Generale e offrono occ configreport:generateun'opzione per ottenere un report di configurazione più completo quando necessario.
Concentrati sul primo errore associato alla richiesta non riuscita, non su ogni avviso che lo segue. Le categorie utili includono timeout delle richieste, spazio di archiviazione insufficiente, impossibilità di creare o rinominare un file temporaneo, errori di autorizzazione, eccezioni WebDAV, risposte HTTP 413/502/504 e errori di blocco dei file. Se imposti temporaneamente il livello di registrazione di ownCloud su DEBUG, riportalo al livello normale in seguito; ownCloud avverte che una registrazione dettagliata può influire sulle prestazioni del server. Consulta la documentazione ufficiale sulla configurazione della registrazione .
Questo è uno dei controlli più importanti per un blocco del 99%. ownCloud Server 11.0 spiega che i caricamenti possono utilizzare più di un'area temporanea. La directory temporanea di caricamento PHP deve avere spazio per i blocchi attivi, mentre la directory di caricamento utente raccoglie i blocchi di un file fino al completamento del caricamento.
Secondo la documentazione di ownCloud relativa al caricamento di file di grandi dimensioni , lo spazio temporaneo PHP dovrebbe essere pianificato approssimativamente come il numero di caricamenti simultanei moltiplicato per la dimensione dei blocchi. Ancora più importante, per un singolo file di grandi dimensioni, la directory di caricamento dell'utente necessita temporaneamente di spazio paragonabile alla dimensione finale del file, poiché contiene i blocchi fino al completamento dell'assemblaggio. Una volta terminato il caricamento, ownCloud scrive i blocchi nella destinazione finale e li rimuove.
Controlla il filesystem che contiene la directory dei dati, la directory temporanea di PHP e qualsiasi posizione configurata tramite OWNCLOUD_DAV_CHUNK_BASE_DIR. Verifica anche la destinazione effettiva, soprattutto se la destinazione è una memoria esterna. Un server può avere molto spazio libero su /mentre un volume di dati separato è pieno.
Non spostare manualmente i file all'interno o all'esterno della directory dati di ownCloud per "completare" il caricamento. ownCloud avverte che la sua directory dati è esclusiva dell'applicazione; modifiche dirette possono causare incongruenze di sincronizzazione e nel database.
Una quota utente può bloccare un file finale di grandi dimensioni anche quando l'area di staging per il caricamento ha spazio sufficiente. Verifica la quota dell'utente interessato e, se pertinente, la capacità e le autorizzazioni di un'unità di archiviazione esterna. Un test utile consiste nel caricare lo stesso file su un altro account o destinazione con spazio chiaramente sufficiente. Se l'errore riguarda l'utente o la cartella anziché il file, la causa più probabile è la quota o i criteri di archiviazione.
Se i log indicano limiti di dimensione o di esecuzione delle richieste, è consigliabile rivedere le impostazioni PHP effettive anziché presumere che i valori in un php.inifile casuale siano attivi. Le direttive comuni includono post_max_size, upload_max_filesize, upload_tmp_dir, max_input_time, max_execution_time, e memory_limit.
Per la configurazione supportata di ownCloud Server 11.0 in ambiente Docker, la documentazione mappa questi elementi alle seguenti variabili d'ambiente: OWNCLOUD_MAX_UPLOAD, OWNCLOUD_TEMP_DIRECTORY, OWNCLOUD_MAX_INPUT_TIME, OWNCLOUD_MAX_EXECUTION_TIME, e OWNCLOUD_MEMORY_LIMIT. Questo è importante perché ownCloud afferma che le implementazioni che utilizzano la sua configurazione Docker dovrebbero utilizzare le variabili d'ambiente fornite anziché basarsi su .htaccessmodelli PHP o di personalizzazione meno recenti.
Non impostare semplicemente ogni limite su un numero estremamente elevato. Un obiettivo migliore è un valore che tenga conto della dimensione massima prevista del file e della connessione legittima più lenta, preservando al contempo le garanzie operative.
ownCloud avverte specificamente che session_lifetimenon deve essere inferiore al tempo di caricamento più lungo previsto. Se lo hai personalizzato, impostalo almeno al numero di secondi richiesto dal caricamento più lento previsto, oppure rimuovi un valore personalizzato non necessario e ripristina il comportamento predefinito supportato.
Vale la pena verificarlo soprattutto quando un file da 500 MB viene completato correttamente, mentre un file di diversi gigabyte continua a non essere completato dopo circa lo stesso lasso di tempo.
La documentazione di ownCloud relativa ai file di grandi dimensioni segnala che i proxy lato client e servizi come Cloudflare possono limitare i caricamenti. Ciò significa che uno stack ownCloud/PHP perfettamente configurato può comunque fallire perché un altro nodo limita il corpo della richiesta, memorizza in un buffer una richiesta lunga, chiude una connessione inattiva o va in timeout mentre ownCloud elabora il caricamento.
Se la tua architettura consente un test amministrativo sicuro, confronta lo stesso caricamento tramite il normale percorso pubblico e tramite un percorso che bypassa il reverse proxy o la CDN. Se il percorso diretto ha successo, esamina la documentazione ufficiale di tale intermediario per quanto riguarda le dimensioni della richiesta, il timeout di caricamento, il buffering e il comportamento di WebDAV. Non indebolire il TLS né esporre pubblicamente il backend solo per eseguire questo test.
Il blocco transazionale dei file è abilitato per impostazione predefinita e protegge i file da modifiche simultanee. ownCloud documenta che è importante anche quando i caricamenti a blocchi vengono assemblati. Su server sovraccarichi, un problema di blocco potrebbe manifestarsi come un trasferimento completato ma non confermato correttamente.
Prima di modificare questo sottosistema, consultare la documentazione relativa al blocco transazionale dei file . ownCloud consiglia di utilizzare un backend di cache in memoria per il blocco in caso di carichi di lavoro più pesanti, anziché affidarsi al blocco del database. Nelle implementazioni cluster, il blocco Redis condiviso è particolarmente importante perché ogni nodo dell'applicazione deve visualizzare lo stesso stato di blocco.
È documentato anche un caso speciale per i caricamenti molto lunghi verso cartelle pubbliche quando la suddivisione in blocchi non è attiva. ownCloud afferma che i caricamenti che durano più di un'ora potrebbero richiedere un blocco sufficientemente grande OWNCLOUD_FILELOCKING_TTL; altrimenti, la garbage collection di Redis potrebbe rimuovere il blocco acquisito all'inizio dell'operazione. Non modificare questa impostazione a meno che il percorso di caricamento non corrisponda a tale scenario.
Dopo aver corretto un problema identificato, riprova con lo stesso file, account, destinazione, browser e percorso di rete. Quindi verifica tre cose: che l'operazione venga completata, che il file appaia nella destinazione con le dimensioni previste e che i log non contengano un nuovo errore per quella richiesta.
Un utile schema di progressione prevede di iniziare con file di piccole dimensioni, poi con file di medie dimensioni e infine con il file della dimensione che inizialmente ha causato l'errore. Se i file di piccole dimensioni vengono sempre elaborati correttamente, ma gli errori iniziano a verificarsi al di sopra di una dimensione che si ripete costantemente, è opportuno concentrarsi sulla capacità di archiviazione e sui limiti di dimensione. Se gli errori iniziano dopo un intervallo di tempo che si ripete, è necessario concentrarsi sulle sessioni e sui timeout. Se si verificano solo attraverso un determinato hostname o percorso di rete, è opportuno concentrarsi sui proxy e sui bilanciatori di carico.
Se hai bisogno di una procedura guidata breve, segui questo ordine: riproduci il problema una volta; leggi i log di ownCloud/PHP/server web; controlla lo spazio di archiviazione dati, temporaneo e a blocchi; verifica la quota; conferma le impostazioni di caricamento e tempo effettive; ispeziona la durata della sessione; bypassa o ispeziona il reverse proxy/CDN; infine, indaga sul blocco transazionale. Questo ordine privilegia le prove e i vincoli infrastrutturali con la più alta probabilità prima di apportare modifiche di configurazione rischiose.
Il dettaglio importante è che il "99%" non è di per sé un codice di errore. Indica dove l'utente ha notato il problema, non quale componente lo ha causato. La soluzione affidabile consiste nel confrontare il timestamp del caricamento non riuscito con le informazioni relative a storage, timeout, proxy, sessione o blocco sul server.
Risolvi l'avviso di Nextcloud relativo alla mancanza di HSTS configurando il server web HTTPS o il proxy inverso, quindi verifica in modo sicuro l'intestazione Strict-Transport-Security.
Risolvi l'errore "CSync Unknown Error" del client ownCloud Desktop ricostruendo il database di sincronizzazione nascosto, quindi verifica la connettività, le autorizzazioni, i nomi dei file, lo spazio su disco e i log.
Il proxy Matrix Sliding Sync è stato archiviato e sostituito. Abilitare la sincronizzazione Simplified Sliding Sync nativa in Synapse, verificare il supporto del client, aggiornare il routing del proxy e testare la sincronizzazione mobile in modo sicuro.
Diagnostica i rallentamenti nella federazione Matrix Synapse e nell'adesione alle stanze verificando la connettività, lo stato dei tentativi del server remoto, le metriche, il carico del database e i limiti di frequenza di adesione.
Configura la conservazione del cestino e le attività in background di Nextcloud per rimuovere automaticamente i file eliminati, verificare l'avvenuta pulizia ed evitare comandi di eliminazione sicura per tutti gli utenti.
Diagnostica l'eco di BigBlueButton e il ritardo audio di WebRTC separando il feedback del microfono dal ritardo di rete, verificando il test dell'eco, i dispositivi del browser, la connettività UDP e il carico del server.
Configura un repository Restic crittografato e un'attività pianificata (cron job) per Nextcloud, includendo la modalità di manutenzione, un dump di MariaDB, la conservazione dei dati, i log e i controlli di ripristino.
Risolvi i problemi di caricamento su ownCloud bloccati al 99% controllando i log, lo spazio di archiviazione temporaneo, lo spazio dei chunk, i limiti PHP, le sessioni, i proxy e il blocco dei file nell'ordine corretto.
Abilita e applica correttamente l'autenticazione a due fattori (2FA) di Zimbra, registra un account amministratore, scegli la verifica tramite TOTP o e-mail e testa l'accesso alla Console di amministrazione.
Configura Mjolnir per la moderazione di Matrix: crea un account bot dedicato, configura la sua sala di controllo, proteggi le stanze, gestisci le liste di ban e verifica le autorizzazioni in modo sicuro.
