Grüner Haken - trotzdem fehlen Dateien

🌐 International support 🇩🇪 Deutsch (german)
,
1

Hallo liebe Leserin, lieber Leser,

Mein Dokumente-Ordner (ca. 140 GB auf einem MacBook Air M2 von 2022, 16 GB Arbeitsspeicher), soll über den Nextcloud-Client synchronisiert werden (Client 3.13.2). Es hat etwa eine Woche gedauert, dann wurde ein grüner Haken angezeigt. Doch es fehlen etwa 15 GB. Also habe ich Verzeichnisse verglichen, und musste feststellen, dass einige größere Dateien nicht synchronisiert wurden.

  • Warum wird der grüne Haken gezeigt, obwohl nicht alles synchronisiert wurde?
  • Wie finde ich nun heraus, welche Dateien im Einzelnen fehlen?
  • Wie bringe ich das System dazu, ganze Arbeit zu leisten?

Auf der Server-Seite arbeitet ein Raspberry Pi 4B mit 4 GB Arbeitsspeicher und einer per USB angeschlossenen magnetischen Festplatte - die Platte hat ein eigenes Netzteil. Installiert ist Nextcloud Hub 8 (29.0.3).

Was ich bisher probiert habe:

  • Ich habe den Client beendet und die (in meinem Dokumente-Ordner versteckt gespeicherten) Dateien .sync_xxx.db, -sync_xxx.db-shm, .sync_xxx.db-wal sowie .sync-exclude.lst gelöscht (statt dem xxx steht da eine Folge von Ziffern und Kleinbuchstaben).

  • Auf dem Server ließ ich den Befehl durchlaufen: ‘sudo -u www-data php /var/www/nextcloud/occ files:scan -v --path=“/meinname/files/” meinname’, um die vorhandenen Dateien neu zu indizieren.

  • Anschließend habe ich den Client wieder gestartet. Zwar ist der Client dann alle Dateien noch einmal durchgegangen, aber die fehlenden Dateien wurden nicht hinzugefügt. Am Ende wurde wieder der grüne Haken angezeigt.

  • selbst gehostet

  • Raspberry Pi 4b, 4 GB Arbeitsspeicher, externe magnetische Festplatte

  • Debian GNU/Linux 12 (bookworm)

  • Nextcloud Version: Nextcloud Hub 8 (29.0.3)

  • PHP Version: 8.2

  • Welche Datenbank? MariaDB

  • Apache 2

  • NC läuft direkt auf Debian, kein Docker usw.

  • Netzwerk: vom MacBook Air über USB-C zur Docking Station, von dort per Netzwerkkabel zu einem Switch, per Kabel zum Router (Fritz!Box), von dort per Kabel zum Raspberry Pi (insgesamt ca. 5 m Kabelstrecke). Alternativ ist WLAN möglich, was aber an der Situation nichts geändert hat.

  • Der Server ist frisch installiert, es ist die erste Synchronisation eines Computers mit diesem Server.

  • Die Logs habe ich angesehen, aber keinen Hinweis auf ausgelassene Dateien gefunden.

Die App “Issue Template” kann nicht installiert werden, weil die folgenden Abhängigkeiten nicht erfüllt sind:
Server version 20 or lower is required.

Vorher hatte ich auf derselben Hardware OwnCloud installiert. Diese Installation hat mehrere Jahre gut funktioniert. Nun wollte ich nach Nextcloud wechseln, weil das mit einer aktuelleren PHP-Version funktioniert, und auch sonst mehr Möglichkeiten bietet … Ich habe eine frische Installation gemacht, und bin eben dabei, meine Daten neu zu synchronisieren.

2

Hallo,
dein Problem kommt mir bekannt vor, obwohl dieses bei mir schon ca. 8 Jahre her ist und auf dem Raspberry Pi 2B entstanden ist.
Ich hätte fünf Fragen dazu, um mir ein besseres Bild machen zu können.

  1. Wie groß sind die Dateien, welche nicht mit hochgeladen werden?
  2. Welche Architektur wird auf dem Raspberry Pi verwendet? 32 oder 64-bit?
  3. Welches Dateisystem wird auf der externen Festplatte verwendet? (ext4, ntfs, fat32, …)
  4. Auf welchen Wert steht ‘upload_max_filesize’ in der php.ini?
  5. Funktioniert der Upload von einer der größeren Dateien über dem Webbrowser?
3

Hallo @Manch_Purist,

einen grünen Haken bekommst Du auch, wenn alle Dateien abgearbeitet sind, welche nicht in der “sync-exclude.list” stehen.
Unter Einstellungen → Allgemein → Ignorierte Dateien bearbeiten, hier einmal nachschauen, ob eventuell Dateien oder auch ganze Verzeichnisse ausgeschlossen sind.

Hier einmal der Inhalt der originalen Datei “sync-exclude.list”:

# This file contains fixed global exclude patterns

*~
~$*
.~lock.*
~*.tmp
]*.~*
]Icon\r*
].DS_Store
].ds_store
*.textClipping
._*
]Thumbs.db
]photothumb.db
System Volume Information

.*.sw?
.*.*sw?

].TemporaryItems
].Trashes
].DocumentRevisions-V100
].Trash-*
.fseventd
.apdisk
.Spotlight-V100

.directory

*.part
*.filepart
*.crdownload

*.kate-swp
*.gnucash.tmp-*

.synkron.*
.sync.ffs_db
.symform
.symform-store
.fuse_hidden*
*.unison
.nfs*

# (default) metadata files created by Syncthing
.stfolder
.stignore
.stversions

My Saved Places.

\#*#

*.sb-*

Ich habe meine Datei noch um einige Einträge erweitert.

4

Eine Datei, die mir aufgefallen ist, ist 3,54 GB groß, die andere 2,75 GB.

Die Architektur ist 64-bit:

Betriebssystem: Linux 6.6.31+rpt-rpi-v8 aarch64
Prozessor: Raspberry Pi 4 Model B Rev 1.2 (4 cores)
Speicher: 3.70 GB

PHP Version: 8.3.9
Speicherlimit: 512 MB
Maximale Ausführungszeit: 3600
Maximale Größe zum Hochladen: 16 GB
OPcache-Revalidierungshäufigkeit: 2
Erweiterungen: Core, date, libxml, openssl, pcre, zlib, filter, hash, json, random, Reflection, SPL, session, standard, sodium, cgi-fcgi, mysqlnd, PDO, xml, apcu, bcmath, bz2, calendar, ctype, curl, dom, mbstring, FFI, fileinfo, ftp, gd, gettext, gmp, iconv, igbinary, imagick, intl, exif, msgpack, mysqli, pdo_mysql, Phar, posix, readline, redis, shmop, SimpleXML, soap, sockets, sysvmsg, sysvsem, sysvshm, tokenizer, xmlreader, xmlwriter, xsl, zip, memcached, Zend OPcache

Dateisystem: ext4, Festplatte sda1, Mount: /media/daten, Größe: 7.22 TB
Verfügbar: 3.80 TB, Verwendet: 48% (3.41 TB)

upload_max_filesize = 16G (in /etc/php/8.3/fpm/php.ini)

Nein. Die 2,75 GB große Datei wird scheinbar hochgeladen. Am Ende kommt aber in der rechten oberen Ecke der Webseite eine Meldung mit rotem Strich: Einige Dateien konnten nicht hochgeladen werden.

Wenn ich während des Hochladens mein temp-Verzeichnis beobachte, werden dort ständig Dateien angelegt, immer so zwei bis vier gleichzeitig, nach folgendem Schema:

-rw------- 1 www-data www-data 4284416 Jul 12 14:05 phpNgDwRf
-rw------- 1 www-data www-data 1785856 Jul 12 14:05 phpQN56zG
-rw------- 1 www-data www-data 1507328 Jul 12 14:05 phpZHUhfV

Am Ende sind diese temporären Dateien wieder weg, die Festplatte rattert aber noch eine Weile, und es wird angezeigt, dass es noch ein paar Sekunden dauern würde. Dann kommt die Fehlermeldung.

Das temporäre Verzeichnis wird auch vom Nextcloud-Client als Zwischenlager genutzt. Dessen Dateien haben das Schema oc_temp_XXXXXX (mit Groß- und Kleinbuchstaben sowie Ziffern).

Irgendwie scheint es nicht zu funktionieren, aus den ganzen Einzelteilen am Ende wieder die Datei zusammenzufügen.

5

Also das Speicherlimit ist relativ klein, bei mir sind es 4G und die OPcache-Revalidierungshäufigkeit sollte auf 60 stehen, sonst passt es eigentlich.

6

So steht es in meiner php.ini:

; How often (in seconds) to check file timestamps for changes to the shared
; memory storage allocation. (“1” means validate once per second, but only
; once per request. “0” means always validate)
;opcache.revalidate_freq=2

Hier geht es also darum, wie oft der Zeitstempel von Dateien im gemeinsam genutzten Speicher geprüft wird. Die Zeile war auskommentiert. Ich habe sie jetzt mal auf “0” gesetzt (always validate).

Ich habe auch noch hier nachgelesen: PHP: Laufzeit-Konfiguration - Manual

How often to check script timestamps for updates, in seconds. 0 will result in OPcache checking for updates on every request.

This configuration directive is ignored if opcache.validate_timestamps is disabled.

Ich habe diesen letzteren Wert auf “1” gesetzt, also “enabled”.

Was das Speicherlimit betrifft: Überall stand zu lesen, dass es auf mindestens 512 MB stehen soll. Ich kann diesen Wert nicht beliebig hoch setzen, schließlich muss meine Hardware ja auch irgendwie mitspielen. Dieses Speicherlimit begrenzt jedenfalls nicht die Dateigröße, welche maximal synchronisiert werden kann, weil große Dateien ja in “Chunks” zerlegt werden. Wenn ich weniger Speicher habe, dann müssen es eben mehr Chunks und kleinere Chunks sein, es kann vielleicht auch länger dauern. Aber die Synchronisierung von großen Dateien sollte trotzdem möglich sein.

7

Hier meine Liste:

.OABK
.typeAttributes.dict
*.photoslibrary
.DS_Store

Außerdem sind natürlich noch die Nextcloud-Client-Datenbanken ausgeschlossen. Ganze Verzeichnisse oder gar die betroffenen (nicht synchronisierten) Dateien sind nicht ausgeschlossen.

8

Im Windows Client kann man einstellen, dass z.B. Dateien über x MB nicht synchronisiert werden.

Evtl keine Fehler auf Server Seite, sondern eine Einstellung am Client

9

Bei dem Client unter MacOS gibt es keine Option, dass Dateien über x MB nicht synchronisiert werden. Die begrenzende Option bezieht sich auf komplette Verzeichnisse.

Die Option lautet: “Um eine Bestätigung bitten, bevor Sie neue Ordner synchronisieren, die größer sind als 500 MB”. Ich kann diese Option also aktiv lassen. Dann bekomme ich eine Liste aller Verzeichnisse präsentiert, welche größer als das eingestellte Limit sind. Ich kann bestätigen, dass ich diese Verzeichnisse ebenfalls synchronisieren möchte. Das passiert dann auch - diese Verzeichnisse werden synchronisiert. Nur eben manche Dateien aus diesen Verzeichnissen nicht, darunter auch zwei große Dateien, die über 2 GB groß sind.

Andere Dateien, welche nicht synchronisiert werden, haben ein Leerzeichen zu Beginn oder am Ende des Dateinamens. Dateien mit solchen Namen wurden von einer bestimmten Version von iMovie angelegt (innerhalb von Projekten). Hier kann man eingreifen und Dateien umbenennen.

10

Ok, ob die Begrenzung bei Windows auf Datei oder Ordner ist, müsste ich nun schauen, danke.

Bzgl Leerzeichen, da bekomme ich immer wieder eine Meldung, dass aufgrund diesem Fehler eine Datei nicht synchronisiert werden kann.

Kann man da wo einsehen welche Dateien das sind?
Wir haben aktuell mit dem Problem zu kämpfen, dass mein Chef diese Meldung minütlich bekommt, dass irgendwas nicht synchronisiert werden kann. Finden aber kein Log mit den Dateien und dem Problem

11

Diese Fehler kommen mir sehr bekannt vor. Ich habe da einige Benutzer, welche in einem Dateinamen ganze Sätze hineinschreiben inklusive eines Punktes am Ende des Satzes.
Einen Punkt als letztes Zeichen im Ordner- oder Dateinamen kann die Synchronisation absolut gar nicht verarbeiten.

12

Ja, das kann man sich ansehen. In der Nextcloud-Weboberfläche im Protokolldatei-Leser kann man sich die Zeilen mit webdav-Fehlern heraussuchen. In einer solchen Fehlerzeile kann ich ganz rechts auf die drei Punkte klicken, und einen “formatierten Eintrag kopieren”. Den füge ich in einen Texteditor ein, und sehe es mir an, ob ich den Fehler beheben kann.

13

Zusätzlich kann man in /var/log/apache2 bzw nginx die access_log und error_log “befragen”.
Als Anhalt dient der Zeitstempel und die IP-Adresse im Log. Eine fehlerhafte Übertragung kann anhand des Returncodes (<>200) entdeckt werden. Könnte auch helfen, den Grund zu finden.

14

Unterdessen habe ich mich weiter mit meinem Problem auseinandergesetzt, dass ich nämlich keine großen Dateien auf meinen Server hochladen kann. Die Datei, welche ich zur Zeit zum Testen nutze, ist 3,54 GB groß. Jedes Mal läuft der Upload bis zum Ende, um dann mit einer Fehlermeldung abzubrechen: Einige Dateien konnten nicht hochgeladen werden.

Ich habe einige Versuche mit unterschiedlichen Speicherlimits gemacht, bis hin zu 4096 MB. Doch dies hat nichts geändert.

Dann habe ich folgenden Vorschlag durchgearbeitet: https://medium.com/@sbuckpesch/apache2-and-php-fpm-performance-optimization-step-by-step-guide-1bfecf161534

Ich habe also das Script heruntergeladen. Die Nutzung meines Speichers sieht im Moment so aus:

 Private  +   Shared  =  RAM used	Program

216.0 KiB +  60.5 KiB = 276.5 KiB	agetty
292.0 KiB + 121.5 KiB = 413.5 KiB	cron
316.0 KiB + 124.5 KiB = 440.5 KiB	thd
484.0 KiB + 652.0 KiB =   1.1 MiB	avahi-daemon (2)
  1.1 MiB + 232.5 KiB =   1.4 MiB	dbus-daemon
  1.0 MiB + 656.5 KiB =   1.6 MiB	systemd-timesyncd
764.0 KiB + 932.0 KiB =   1.7 MiB	sudo (2)
  1.3 MiB + 690.5 KiB =   1.9 MiB	systemd-logind
  1.3 MiB +   1.0 MiB =   2.3 MiB	polkitd
  2.3 MiB + 370.5 KiB =   2.6 MiB	bluetoothd
  2.7 MiB + 125.5 KiB =   2.8 MiB	bash
  2.4 MiB + 638.5 KiB =   3.0 MiB	systemd-journald
  3.6 MiB + 149.5 KiB =   3.7 MiB	systemd-udevd
  4.5 MiB + 391.5 KiB =   4.9 MiB	wpa_supplicant
  5.4 MiB + 523.5 KiB =   5.9 MiB	redis-server
  2.7 MiB +   3.5 MiB =   6.2 MiB	sshd (3)
  5.2 MiB +   1.4 MiB =   6.6 MiB	ModemManager
  6.9 MiB +   2.7 MiB =   9.6 MiB	NetworkManager
  4.0 MiB +   5.8 MiB =   9.8 MiB	systemd (3)
 16.9 MiB +  19.9 MiB =  36.9 MiB	apache2 (5)
124.2 MiB +  60.4 MiB = 184.6 MiB	php-fpm8.3 (17)
527.3 MiB + 709.5 KiB = 528.0 MiB	mariadbd
---------------------------------
                        815.7 MiB
=================================

Diese Liste kam zustande, während der Upload meiner Testdatei lief.

Aktuell sind bei mir die Einstellungen wie folgt gesetzt:

in der Datei mpm_event.conf:

ServerLimit         674
StartServers          4
MaxRequestWorkers   674

in der Datei www.conf:

pm.max_children     175
pm.start_servers     16
pm.min_spare_servers  8
pm.max_spare_servers 16

Meine Seite “server-status” zeigt mir an:

Parent Server Config. Generation: 1
Parent Server MPM Generation: 0
Server uptime: 11 minutes 47 seconds
Server load: 5.29 5.46 3.22
Total accesses: 342 - Total Traffic: 2.1 GB - Total Duration: 55910
CPU Usage: u112.44 s29.21 cu0 cs.01 - 20% CPU load
.484 requests/sec - 3.0 MB/second - 6.1 MB/request - 163.48 ms/request
2 requests currently being processed, 0 workers gracefully restarting, 73 idle workers

mod_fcgid status:

Total FastCGI processes: 0
SSL/TLS Session Cache Status:
cache type: SHMCB, shared memory: 512000 bytes, current entries: 42
subcaches: 32, indexes per subcache: 88
time left on oldest entries' objects: avg: 124 seconds, (range: 8...278)
index usage: 1%, cache usage: 2%
total entries stored since starting: 104
total entries replaced since starting: 0
total entries expired since starting: 62
total (pre-expiry) entries scrolled out of the cache: 0
total retrieves since starting: 0 hit, 0 miss
total removes since starting: 0 hit, 0 miss

All diese Werte habe während eines laufenden (erfolglosen) Uploads ermittelt. Natürlich schwanken diese Werte bei jedem Refresh der Seite, aber sie geben doch einen Anhaltspunkt.

Im Moment denke ich, dass ich mich nicht weiter mit der Frage der Speichernutzung beschäftigen sollte, da mir langsam die Ideen ausgehen. Ich brauche ein neues Feld, welches ich beackern kann, um es endlich hinzubekommen, auch große Dateien hochladen zu können - besser noch: Ich will diese Dateien ja eigentlich mit dem Client synchronisieren, und nicht von Hand einzeln hochladen.

Wer kann mir den entscheidenden Tipp geben? Wo kann ich noch suchen?

15

Ich habe einen Versuch gemacht, um zu sehen, bis zu welcher Größe Dateien synchronisiert werden: Ich habe Dateien erzeugt, die 1 GB, 1.1 GB, 1.2 GB … 2 GB groß sind. Diese habe ich durch den Client synchronisieren lassen. Nach zehn Stunden sieht mein Verzeichnis auf dem Server so aus:

-rw-r--r-- 1 www-data  418279347 Jul 17 19:09 file_1_8GB.ocTransferId1081342346.part
-rw-r--r-- 1 www-data 2004895600 Jul 17 15:43 file_2GB.ocTransferId1036060712.part
-rw-r--r-- 1 www-data  619213792 Jul 17 14:55 file_1_9GB.ocTransferId33267895.part
-rw-r--r-- 1 www-data  619158008 Jul 17 14:55 file_1_8GB.ocTransferId220525775.part
-rw-r--r-- 1 www-data  634239480 Jul 17 13:55 file_1_8GB.ocTransferId1097368104.part
-rw-r--r-- 1 www-data  626830842 Jul 17 13:55 file_2GB.ocTransferId1009922833.part
-rw-r--r-- 1 www-data  631603657 Jul 17 13:55 file_1_9GB.ocTransferId2013087274.part
-rw-r--r-- 1 www-data  581414219 Jul 17 13:17 file_1_5GB.ocTransferId205466800.part
-rw-r--r-- 1 www-data  578510720 Jul 17 13:17 file_1_6GB.ocTransferId861377399.part
-rw-r--r-- 1 www-data  577948937 Jul 17 13:17 file_1_7GB.ocTransferId322326804.part
-rw-r--r-- 1 www-data 1175872813 Jul 17 12:37 file_2GB.ocTransferId2070853669.part
-rw-r--r-- 1 www-data  735974234 Jul 17 12:13 file_1_9GB.ocTransferId1296007541.part
-rw-r--r-- 1 www-data  705763499 Jul 17 12:12 file_1_8GB.ocTransferId856467973.part
-rw-r--r-- 1 www-data  763206115 Jul 17 12:08 file_1_7GB.ocTransferId1503818996.part
-rw-r--r-- 1 www-data  655675519 Jul 17 11:43 file_1_6GB.ocTransferId829001882.part
-rw-r--r-- 1 www-data  615632203 Jul 17 11:42 file_1_5GB.ocTransferId130831301.part
-rw-r--r-- 1 www-data  662578084 Jul 17 11:40 file_1_4GB.ocTransferId174548358.part
-rw-r--r-- 1 www-data 1782579200 Jul 17 09:19 file_1_7GB
-rw-r--r-- 1 www-data 1677721600 Jul 17 09:19 file_1_6GB
-rw-r--r-- 1 www-data 1572864000 Jul 17 09:18 file_1_5GB
-rw-r--r-- 1 www-data 1468006400 Jul 17 09:18 file_1_4GB
-rw-r--r-- 1 www-data 1363148800 Jul 17 09:17 file_1_3GB
-rw-r--r-- 1 www-data 1258291200 Jul 17 09:17 file_1_2GB
-rw-r--r-- 1 www-data 1153433600 Jul 17 09:17 file_1_1GB
-rw-r--r-- 1 www-data 1048576000 Jul 17 09:16 file_1GB

Obwohl beispielsweise die 1.4 GB-große Datei übertragen wurde, ist die temporäre .part-Datei immer noch vorhanden. Mal sehen, ob das System diese temporäre Datei irgendwann aufräumt. Genauso verhält es sich auch mit den Dateien 1.5 GB, 1.6 GB und 1.7 GB. Von den noch größeren Dateien existieren ebenfalls temporäre Dateien, hier ist es aber noch nicht geglückt, die ganze Datei auf den Server zu übertragen.

Nach zehn Stunden sind also alle Dateien bis 1.7 GB übertragen, größere Dateien wurden nicht übertragen. Die 1.7 GB große Datei wurde übrigens bereits nach wenigen Minuten übertragen - ich hatte den Test um 9:00 Uhr gestartet. Den ganzen Tag über ist es nicht geglückt, die größeren Dateien zu übertragen. Die Grenze meines Systems liegt also im Moment bei 1.7 GB.

Wie kann ich es erreichen, dass auch größere Dateien als 1.7 GB synchronisiert werden?

16

Seit meinem letzten Eintrag habe ich noch einige Änderungen an meiner Konfiguration vorgenommen, Timeouts erhöht oder verringert, Puffer vergrößert und verkleinert - eben all die Dinge, die man tut, wenn man nicht wirklich weiß, wo der Hase im Pfeffer liegt.

Am Montag habe ich nun einen Schnitt gemacht, und Nextcloud noch einmal neu installiert, diesmal mit Docker: “Nextcloud All in One” (GitHub - nextcloud/all-in-one: 📦 The official Nextcloud installation method. Provides easy deployment and maintenance with most features included in this one Nextcloud instance.)

Für mich bedeutete dies, erste Schritte mit Docker zu machen: Wie bekommt man das gestartet und gestoppt, wie läuft ein eventuelles Update ab, wo bleiben meine Daten usw. Alle Informationen, die ich hierzu brauchte, waren in dem verlinkten Text enthalten. Ein Detail musste ich woanders finden: Wie finde ich den verwendeten “Passphrase” heraus? Mit diesem Befehl:

sudo docker exec nextcloud-aio-mastercontainer grep password /mnt/docker-aio-config/data/configuration.json

Jetzt läuft mein System (Raspberry Pi 4B mit 4GB, zwei angeschlossene stromversorgte Festplatten zu je 7 TB - die eine mit den Daten, die andere als Backup). Ich kann auch große Dateien synchronisieren (am Client habe ich nichts geändert, an dem lag es also nicht). Alles läuft mit annehmbaren Tempo - natürlich nutze ich kein Talk, dafür wäre meine Hardware zu schwach.

Für mich ist damit meine Suche beendet, dieser Gesprächsfaden darf also gerne verknotet werden. Ich bedanke mich bei allen, die sich zu Wort gemeldet haben (in order of appearance):

Manch_Purist

2 Likes