Upload bricht ab, Zielverzeichnis gesperrt

Hallo, ich bin neu, habt Geduld mit mir!

Ich habe NC als 1-Klick-Installation auf einem Manitu-Webspace zum Laufen gebracht mit dem Ziel, meinen Dropbox-Account einzusparen. Ich dachte, in Zeiten von Trump wĂ€re es vielleicht eine gute Idee, auf den einen oder anderen US-Provider zu verzichten. Ich dachte auch, wenn mir mein Mail-Provider, mit dem ich bisher sehr zufrieden war, eine 1-Klick-Installation anbietet, dann wĂŒrde ich - zumindest beim Filesharing - von KonfigurierungstĂ€tigkeiten weitgehend verschont blieben. User und Freigaben einrichten, das schon, aber sehr viel mehr auch nicht. Dachte ich.

Das war wohl etwas naiv, denn ich kriege nicht einmal den aus meiner Sicht einfachsten Einsatzfall “Filesharing wie bei Dropbox” hin. Es scheitert momentan daran, Dateien mit dem NC-Client zum NC-Server vollstĂ€ndig hochzuladen. Ich nutze eine 50Mbps-Internetanbindung, Performanceprobleme kenne ich nicht. Dateien unterhalb einer Grösse von 35MB werden problemlos ĂŒbertragen, ĂŒber 45MB gibt es reproduzierbar Fehler, irgendwo dazwischen scheint ein Limit zu liegen. Und ja, es geht wirklich nur um MB, nicht etwa um GB. Ich habe umfangreiche Diagnoseunterlagen fĂŒr den Manitu-Support erstellt und von dort als Antwort erhalten, ein Fehler dieser Art wĂ€re ihnen noch nie begegnet, ich sollte mich an die NC-Community wenden. Hier bin ich also. Bei vergleichenden Tests mit der MagentaCloud sind ĂŒbrigens keinerlei Fehler aufgetreten. Und in zig Jahren Dropbox zuvor auch nicht.

Versionsnummern der eingesetzten Komponenten:
NC 32.0.5
MariaDB V? (mysql 10.11.10)
PHP 8.2
NC-Client 4.0.6 (stable, kein Proxy, keine Bandbreitenbegrenzung)
W11 Home 25H2

Fehlerbild: Dateien oberhalb des Grössenlimits werden unvollstÀndig hochgeladen. Sie sind auf FTP-Ebene als Dateien mit der Endung .part sichtbar, erscheinen aber _nicht_ in der NC-Webanwendung. Das Zielverzeichnis ist in so einem Fall gesperrt. Kleinere Dateien werden wie erwartet sowohl auf FTP-Ebene angezeigt als auch in der NC-Webanwendung.

Fehlermeldungen des NC-Clients:
. “Es ist ein unerwarteter Fehler aufgetreten. Bitte die Synchronisierung erneut versuchen oder an Ihre Serveradministration wenden, wenn das Problem weiterhin besteht.”
. “Die Ressource, auf die Sie zuzugreifen versuchen, ist derzeit gesperrt und kann nicht geĂ€ndert werden. Versuchen Sie bitte, sie spĂ€ter zu Ă€ndern, oder wenden sich fĂŒr Hilfe an Ihre Serveradministration.”
Der NC-Client versucht endlos und erfolglos, die abgebrochenen Übertragungen zu Ende zu bringen.

Um die Reste der Übertragungsfehler auf Dateiebene zu beseitigen, könnte ich sie per FTP löschen. Meine Frage, ob ich die dazugehörigen EintrĂ€ge auch in der Datenbank löschen mĂŒsste (und wenn ja, wie), wurde vom Manitu-Support nicht beantwortet. Hat jemand aus der Community schon mal ein Ă€hnliches Problem gehabt? Ich bin fĂŒr jeden Tipp dankbar.

Servus @goldie0049 willkommen im community forum :waving_hand:

ja das scheint sinnvoll du solltest die reste löschen


auch das ist richtig und wĂŒrde bedeuten einen “file scan” mit dem OCC-befehl occ files:scan --all durchzufĂŒhren

du mĂŒsstest dafĂŒr per commandozeile also SSH auf deinen webspace zugreifen und den OCC-befehl absetzen. eine beschreibung wie das geht findest du im Manitu Wiki:

ĂŒbrigens ist der Manitu support sehr kompetent und freundlich (eigene erfahrung)
 wenn du par tout nicht weiter kommst, die helfen dir bestimmt.

Bei frĂŒheren Fragen zu Mail war der Manitu-Support sehr hilfreich, das ist wahr.

Auf die Frage, wie man verwaiste DatenbankeintrÀge löscht, kam die Antwort (Zitat)

“Bitte wenden Sie sich hier an die Nextcloud-Community.
FĂŒr die Nextcloud selbst bieten wir keine UnterstĂŒtzung an.“

Ich verstehe, dass Manitu managed Support verkaufen will. Aber es sollte wenigstens die Basis-FunktionalitÀt gegeben sein, und das ist hier eben nicht der Fall.

Aber danke fĂŒr die Antwort, ich werde mich mit OCC-Befehlen genauer beschĂ€ftigen.

:grin: das hast du ja gemacht :check_mark:

Genau, und mit dem OCC-Befehl im Hinterkopf kann ich vielleicht auch die Auswirkungen des Fehlers beseitigen. Obwohl das sekundĂ€r ist, handelt es sich doch “nur” um TrĂŒmmer einer Testumgebung.

Allerdings kann ich nicht produktiv werden, solange nicht die Ursache des reproduzierbaren (!) Fehlers beseitigt ist. Ich will einfach nicht glauben, dass es ein gewolltes Upload-Limit gibt, das bei 40 ± 5 MB liegt. Aber falls es doch ein Limit gibt, dann gibt es bestimmt auch eine Datei A mit einem Eintrag B, der auf einen Wert C geÀndert werden muss, um das Limit auf 100 MB zu schieben; damit könnte ich leben.

Any ideas?

@goldie0049

deine beschreibung lĂ€sst vermuten, dass du mit der windows desktop app auf eine grĂ¶ĂŸenbeschrĂ€nkung der upload datei erhĂ€ltst? wenn du also im browser die datei hochlĂ€dst, hast du keine beschrĂ€nkung?

ich habe leider kein windows und verwende keinen desktop-sync-client, bin jedoch ziemlich sicher, dass die dektop app eine einstellung besitzt um die maximale dateigrĂ¶ĂŸe einzuschrĂ€nken.

normalerweise kannst du das in den einstellungen im betroffenen konto in der desktop app definieren:

wenn ich mir jedoch die dokumentation ansehe:

und aus erfahrung weiß, dass Manitu one click nextcloud paket “nur” beschrĂ€nkten PHP-speicher zur verfĂŒgung stellt, daher vermute ich, dass du da an deine grenzen stoßen wirst. siehe hier:

persönlich ist mir das one click hosting zu administrationsintensiv, aber funktionsfĂ€hig. daher self-hosting fĂŒr vollen umfang. das ist kein hexenwerk.

@scubamuc: Erstmal danke fĂŒr die viele MĂŒhe, die du hier investierst.

Der Fehler tritt nicht nur auf beim Upload mit dem NC-Sync-Client, sondern auch beim manuellen Upload im Browser, beim eben durchgefĂŒhrten Test schon zwischen 21 und 31 MB; von dem Problem “Uploading big files > 512 MB” bin ich also weit entfernt. Wenn ich die Doku richtig verstanden habe, sollen große Dateien fĂŒr den Upload in “Chunks” zerlegt werden, wobei die Standard-Chunk-GrĂ¶ĂŸe 100 MB betrĂ€gt; da liegen wir also auch weit drunter.

Hier Ausschnitte aus 2 Log-Files, in denen der Fehler dokumentiert ist.

Ausschnitt aus web.err.log

##########################
2a02:8071:50c5:52c0:70f1:2935:1f11:7a14 \[2026-03-06 09:38:37.006102\] \[proxy_fcgi:error\] \[pid 1368\] (32)Broken pipe: AH01075: Error dispatching request to : (sending stdin)
2a02:8071:50c5:52c0:70f1:2935:1f11:7a14 \[2026-03-06 09:38:37.023958\] \[proxy_fcgi:error\] \[pid 1369\] (32)Broken pipe: AH01075: Error dispatching request to : (sending stdin)
2a02:8071:50c5:52c0:70f1:2935:1f11:7a14 \[2026-03-06 09:38:37.047079\] \[proxy_fcgi:error\] \[pid 1370\] (32)Broken pipe: AH01075: Error dispatching request to : (sending stdin)
2a02:8071:50c5:52c0:70f1:2935:1f11:7a14 \[2026-03-06 09:39:02.056632\] \[proxy_fcgi:error\] \[pid 1365\] (32)Broken pipe: AH01075: Error dispatching request to : (sending stdin)
2a02:8071:50c5:52c0:70f1:2935:1f11:7a14 \[2026-03-06 09:39:52.116596\] \[proxy_fcgi:error\] \[pid 1371\] (32)Broken pipe: AH01075: Error dispatching request to : (sending stdin)

### 

Auf FTP-Ebene werden genau 5 Dateien mit der Endung .part angezeigt, das korrespondiert also mit diesen Error-EintrÀgen.

Ausschnitt aus web.log

######################
2a02:8071:50c5:52c0:70f1:2935:1f11:7a14 - - \[06/Mar/2026:09:37:00 +0100\] “PUT /ocs/v2.php/apps/user_status/api/v1/heartbeat?format=json HTTP/1.1” 200 148 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36” 3471 2618
2a02:8071:50c5:52c0:70f1:2935:1f11:7a14 - - \[06/Mar/2026:09:37:00 +0100\] “PROPFIND /remote.php/dav/files/mgr/testdateien_20260306_browser/ HTTP/1.1” 404 258 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36” 4310 2637
2a02:8071:50c5:52c0:70f1:2935:1f11:7a14 - - \[06/Mar/2026:09:37:00 +0100\] “MKCOL /remote.php/dav/files/mgr/testdateien_20260306_browser/ HTTP/1.1” 201 - “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36” 1150 609
2a02:8071:50c5:52c0:70f1:2935:1f11:7a14 - - \[06/Mar/2026:09:37:00 +0100\] “PROPFIND /remote.php/dav/files/mgr/ HTTP/1.1” 207 1396 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36” 2109 2222
2a02:8071:50c5:52c0:70f1:2935:1f11:7a14 - - \[06/Mar/2026:09:37:14 +0100\] “GET /ocs/v2.php/apps/notifications/api/v2/notifications HTTP/1.1” 304 - “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36” 3405 2463
2a02:8071:50c5:52c0:70f1:2935:1f11:7a14 - - \[06/Mar/2026:09:37:24 +0100\] “PUT /ocs/v2.php/apps/user_status/api/v1/heartbeat?format=json HTTP/1.1” 200 148 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36” 3439 2618
2a02:8071:50c5:52c0:70f1:2935:1f11:7a14 - - \[06/Mar/2026:09:37:00 +0100\] “PUT /remote.php/dav/files/mgr/testdateien_20260306_browser/fsutil_11000000.dat HTTP/1.1” 201 - “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36” 11016087 718
2a02:8071:50c5:52c0:70f1:2935:1f11:7a14 - - \[06/Mar/2026:09:37:44 +0100\] “GET /ocs/v2.php/apps/notifications/api/v2/notifications HTTP/1.1” 304 - “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36” 3405 2463
2a02:8071:50c5:52c0:70f1:2935:1f11:7a14 - - \[06/Mar/2026:09:38:14 +0100\] “GET /ocs/v2.php/apps/notifications/api/v2/notifications HTTP/1.1” 304 - “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36” 3437 2463
2a02:8071:50c5:52c0:70f1:2935:1f11:7a14 - - \[06/Mar/2026:09:37:00 +0100\] “PUT /remote.php/dav/files/mgr/testdateien_20260306_browser/fsutil_21000000.dat HTTP/1.1” 201 - “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36” 21031679 2385
2a02:8071:50c5:52c0:70f1:2935:1f11:7a14 - - \[06/Mar/2026:09:37:00 +0100\] “PUT /remote.php/dav/files/mgr/testdateien_20260306_browser/fsutil_31000000.dat HTTP/1.1” 503 2008 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36” 24218731 4045
2a02:8071:50c5:52c0:70f1:2935:1f11:7a14 - - \[06/Mar/2026:09:37:00 +0100\] “PUT /remote.php/dav/files/mgr/testdateien_20260306_browser/fsutil_51000000.dat HTTP/1.1” 503 2008 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36” 24628610 7775
2a02:8071:50c5:52c0:70f1:2935:1f11:7a14 - - \[06/Mar/2026:09:37:00 +0100\] “PUT /remote.php/dav/files/mgr/testdateien_20260306_browser/fsutil_41000000.dat HTTP/1.1” 503 2008 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36” 24809076 7775
2a02:8071:50c5:52c0:70f1:2935:1f11:7a14 - - \[06/Mar/2026:09:38:44 +0100\] “GET /ocs/v2.php/apps/notifications/api/v2/notifications HTTP/1.1” 304 - “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36” 3469 2463
2a02:8071:50c5:52c0:70f1:2935:1f11:7a14 - - \[06/Mar/2026:09:38:47 +0100\] “PUT /ocs/v2.php/apps/user_status/api/v1/heartbeat?format=json HTTP/1.1” 200 148 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36” 1267 951
2a02:8071:50c5:52c0:70f1:2935:1f11:7a14 - - \[06/Mar/2026:09:38:59 +0100\] “PUT /index.php/apps/files/api/v1/config/grid_view HTTP/1.1” 200 72 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36” 3422 2541
2a02:8071:50c5:52c0:70f1:2935:1f11:7a14 - - \[06/Mar/2026:09:38:59 +0100\] “PROPFIND /remote.php/dav/files/mgr/ HTTP/1.1” 207 1391 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36” 2109 2217
2a02:8071:50c5:52c0:70f1:2935:1f11:7a14 - - \[06/Mar/2026:09:37:41 +0100\] “PUT /remote.php/dav/files/mgr/testdateien_20260306_browser/fsutil_61000000.dat HTTP/1.1” 503 2008 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36” 20869735 2378
2a02:8071:50c5:52c0:70f1:2935:1f11:7a14 - - \[06/Mar/2026:09:39:04 +0100\] “PUT /index.php/apps/files/api/v1/config/grid_view HTTP/1.1” 200 73 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36” 1251 875

Die Testdateien mit den GrĂ¶ĂŸen 11 und 21 MB werden fehlerfrei ĂŒbertragen und im Browser angezeigt.
Die Testdateien mit den GrĂ¶ĂŸen 31, 41, 51, 61, 71, 81 und 91 MB werden im Browser nicht angezeigt.
Es wird immer wieder versucht, die Dateien hochzuladen. Der Upload muss manuell abgebrochen werden.

Hinweis: im Log sind ZeitsprĂŒnge zu sehen, zB von 9:37:44 auf 9:38:14 und wieder zurĂŒck auf 9:37:00
Ungewöhnlich; Logs von anderen Produkten, die ich bisher gesehen habe, waren chronologisch geordnet.

dafĂŒr sind wir doch hier :sunny:

der web.err.log hilft leider wenig.
es wÀre gut wenn du die nextcloud.log zeigen könntest
auch interessant, deine config occ config:list
am besten wie oben beschrieben mittels OCC befehl per SSH auslesen
 aber einige OCC befehle wie “config:list” lassen sich bequem mit der Nextcloud app occweb absetzen
 wird sogar von Manitu empfohlen aber mit vorsicht zu genießen,

Hier kommt der Eintrag der nextcloud.log, Kommentar am Ende:

{“reqId”:“aaqVcpfRlnCk1G1XXSvLKgAAAFo”,“level”:3,“time”:“2026-03-06T08:51:42+00:00”,“remoteAddr”:“2a02:8071:50c5:52c0:70f1:2935:1f11:7a14”,“user”:“mgr”,“app”:“no app in context”,
“method”:“PUT”,“url”:“/remote.php/dav/files/mgr/testdateien_20260306_browser/fsutil_81000000.dat”,“scriptName”:“/remote.php”,
 “message”:“Erwartete Dateigr\\u00f6\\u00dfe von 81000000 bytes, aber 11337728 bytes gelesen (vom Nextcloud-Client) und geschrieben (in den Nextcloud-Speicher). Dies kann entweder ein Netzwerkproblem auf der sendenden Seite oder ein Problem beim Schreiben in den Speicher auf der Serverseite sein.”,
 “userAgent”:“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36”,“version”:“32.0.5.0”,
 “exception”:{“Exception”:“Sabre\\DAV\\Exception\\BadRequest”,
 “Message”:“Erwartete Dateigr\\u00f6\\u00dfe von 81000000 bytes, aber 11337728 bytes gelesen (vom Nextcloud-Client) und geschrieben (in den Nextcloud-Speicher). Dies kann entweder ein Netzwerkproblem auf der sendenden Seite oder ein Problem beim Schreiben in den Speicher auf der Serverseite sein.”,“Code”:0,“Trace”:\[
 {“file”:“/home/sites/site123456789/web/my.domain.de/apps/dav/lib/Connector/Sabre/Directory.php”,“line”:119,
 “function”:“put”,“class”:“OCA\\DAV\\Connector\\Sabre\\File”,“type”:“->”},
 {“file”:“/home/sites/site123456789/web/my.domain.de/3rdparty/sabre/dav/lib/DAV/Server.php”,“line”:1098,
 “function”:“createFile”,“class”:“OCA\\DAV\\Connector\\Sabre\\Directory”,“type”:“->”,“args”:\[“\*\*\* sensitive parameters replaced ***“\]},
 {“file”:”/home/sites/site123456789/web/my.domain.de/3rdparty/sabre/dav/lib/DAV/CorePlugin.php",“line”:504,
 “function”:“createFile”,“class”:“Sabre\\DAV\\Server”,“type”:“->”,“args”:\["*** sensitive parameters replaced \*\*\*”\]},
 {“file”:“/home/sites/site123456789/web/my.domain.de/3rdparty/sabre/event/lib/WildcardEmitterTrait.php”,“line”:89,
 “function”:“httpPut”,“class”:“Sabre\\DAV\\CorePlugin”,“type”:“->”},
 {“file”:“/home/sites/site123456789/web/my.domain.de/3rdparty/sabre/dav/lib/DAV/Server.php”,“line”:472,
 “function”:“emit”,“class”:“Sabre\\DAV\\Server”,“type”:“->”},
 {“file”:“/home/sites/site123456789/web/my.domain.de/apps/dav/lib/Connector/Sabre/Server.php”,“line”:211,
 “function”:“invokeMethod”,“class”:“Sabre\\DAV\\Server”,“type”:“->”},
 {“file”:“/home/sites/site123456789/web/my.domain.de/apps/dav/lib/Server.php”,“line”:424,
 “function”:“start”,“class”:“OCA\\DAV\\Connector\\Sabre\\Server”,“type”:“->”},
 {“file”:“/home/sites/site123456789/web/my.domain.de/apps/dav/appinfo/v2/remote.php”,“line”:22,
 “function”:“exec”,“class”:“OCA\\DAV\\Server”,“type”:“->”},
 {“file”:“/home/sites/site123456789/web/my.domain.de/remote.php”,“line”:151,“args”:\[“/home/sites/site123456789/web/my.domain.de/apps/dav/appinfo/v2/remote.php”\],
 “function”:“require_once”}\],
 “File”:“/home/sites/site123456789/web/my.domain.de/apps/dav/lib/Connector/Sabre/File.php”,“Line”:260,
 “message”:“Erwartete Dateigr\\u00f6\\u00dfe von 81000000 bytes, aber 11337728 bytes gelesen (vom Nextcloud-Client) und geschrieben (in den Nextcloud-Speicher). Dies kann entweder ein Netzwerkproblem auf der sendenden Seite oder ein Problem beim Schreiben in den Speicher auf der Serverseite sein.”,
 “exception”:{},“CustomMessage”:“Erwartete Dateigr\\u00f6\\u00dfe von 81000000 bytes, aber 11337728 bytes gelesen (vom Nextcloud-Client) und geschrieben (in den Nextcloud-Speicher). Dies kann entweder ein Netzwerkproblem auf der sendenden Seite oder ein Problem beim Schreiben in den Speicher auf der Serverseite sein.”}}

Manuell ZeilenumbrĂŒche eingefĂŒgt, um den Eintrag fĂŒr Nextcloud-Laien wie mich besser lesbar zu machen. Site und Domain maskiert.

Das ist der einzige Eintrag, der zu diesem Test gehört. Er betrifft die 81MB-Datei, vermutlich weil diese Datei in dem Moment ĂŒbertragen wurde, als ich den Upload manuell beendet habe.
EintrĂ€ge zu den Dateien der GrĂ¶ĂŸe 11 und 21MB sind nicht enthalten. Und das ist auch gut so, denn die wurden ja fehlerfrei ĂŒbertragen.
EintrĂ€ge zu den Dateien der GrĂ¶ĂŸe 31, 41, 51, 61 und 71MB sind nicht enthalten. Die dazugehörigen Übertragungen wurden abgebrochen, es existieren PART-Dateien.
Ein Eintrag zur Datei der GrĂ¶ĂŸe 91MB ist nicht enthalten. Diese Übertragung wurde vermutlich noch gar nicht begonnen.

occweb habe ich installiert und “config:list” abgesetzt. FĂŒr das Ausgabeformat muss ich mich entschuldigen. Es ist mir nicht gelungen, die Ausgabe in eine Datei umzuleiten. Deshalb habe ich die Ausgabe aus dem Browserfenster rauskopiert.

jawohl, danke das wird reichen

musst du nicht, habs schon bereinigt und unnötige daten aus dem thread gelöscht. :slightly_smiling_face:

macht nichts
 die erforderlichen infos sind doch da

ich werde mich mal aus dem fenster lehnen und behaupten, dass dein speicherplatz zur neige ging.

bitte denke auch daran, Manitu löscht deine upgrade-backups nicht automatisch weg! also je nachdem wie lange deine Nextcloud schon lĂ€uft und wie oft du deine Nextcloud schon aktualisiert hast, musst du die update-backups selbstĂ€ndig aus dem backup verzeichnis löschen um den speicherplatz frei zu geben. anscheinend gibt es auch ein dateianzahl-kontingent das ĂŒberschritten wird wenn du die upgade-backups nicht manuell löschst. siehe dazu: https://wiki.manitu.de/index.php?title=Wartungsaufgaben_bei_Nextcloud&mobileaction=toggle_view_desktop#Bereinigen_der_automatischen_Backups_nach_einem_Update

Ordner löschen

Bei einem Update legt Nextcloud automatisch ein Backup fĂŒr Sie an. Dieses Backup ist natĂŒrlich gut und sinnvoll, belegt jedoch (gerade, wenn Ihre Installation schon mehr genutzt und â€œĂ€lter” ist und damit mehr Updates durchgefĂŒhrt wurden) einen großen Teil von Ihrem Speicherplatz-Kontingent und von der maximalen Anzahl der erlaubten Dateien in Ihrem Webhosting-Paket. Bei einem Update von Nextcloud 21.0.1 auf 21.0.2 war das Backup fast 500 Megabyte groß und enthielt fast 22.000 einzelne Dateien.

damit sollte sich dein problem lösen lassen
 schon schade, dass Manitu Support dir diesen rat nicht geben konnte?

du kannst die upgrade-backups bequem mit dem FTP-Client löschen
 oder per SSH wie in dem wikieintrag erwĂ€hnt löschen. denk dran die berechtigungen fĂŒr das backup verzeichnis zu setzen und wieder zurĂŒck zu setzen wenn die backups weg sind


viel spaß und viel erfolg

Speicherplatz habe ich reichlich, belegt sind ca 3 GB mit ca 30.000 Dateien. NC habe ich vor ca 1 Monat eingerichtet, es gibt weder Updates noch Backups. Bisher ist es nur eine Test-Installation mit 1 Admin und 1 User.

Mein Verdacht ist eher, dass bei der 1-Klick-Installation etwas schepp gelaufen ist. Nehmen wir mal an, ich wĂŒrde eine neue Subdomain aufmachen und NC ein zweites Mal installieren, wĂŒrden sich diese beiden Instanzen in die Quere kommen? Oder andersrum gefragt: wird bei einer 1-Klick-Installation NC mit allen dazugehörigen Komponenten komplett in der Subdomain installiert? Oder gibt es eine ĂŒbergreifende Installation, auf die alle Subdomains Zugriff haben? Ich habe eine Ă€hnliche Frage auch an den Manitu-Support gestellt, keine Antwort :frowning:

@goldie0049 jawohl, klingt gut. Wenn du nicht all zu viele Daten in der Cloud hast, kannst du die exportieren, das cloud verzeichnis löschen und one-click nochmal ausfĂŒhren
 das ist nur ein “kopiervorgang”.

ich bin nach wie vor ĂŒberzeugt von Manitu und deren Support, habe jedoch die one-click cloud verworfen und hoste meine cloud selbst. das wĂ€re fĂŒr dich wohl keine option?

Also wenn du den Verdacht hegst, dass diese 1-Klick-Installation ursĂ€chlich ist und der Support von manitu dir auch nicht helfen will, dann wĂŒrde ich dort nichts mehr neu einrichten, sondern mir einen anderen Anbieter suchen.

Ich habe von manitu im Kontext mit Nextcloud auch noch nichts gehört. Hab mir mal deren Internet-PrĂ€senz angesehen. Da steht zwar “Nextcloud mit nur 1 Klick installierbar” drĂŒber, aber wenn ich mir den Rest so ansehe, dann ist deren Schwerpunkt nicht Nextcloud, sonder Webhosting und Wordpress.

Sieh dich nach einer Alternative um.

@scubamuc

Das werde ich austesten und das Ergebnis hier posten. Kann ein paar Tage dauern.

@adelaar

Ich bin erst vor wenigen Monaten zu Manitu gewechselt, weil DomainFactory (DF) seine Mailserver auf M$365 umgestellt hat und das jede Menge Probleme verursachte. Das Mailen mit Manitu funktioniert einwandfrei, da gibt es nichts zu meckern.

Dann hat Manitu die Tarife umstrukturiert, und plötzlich hatte ich jede Menge Webspace, den ich nicht bestellt hatte. Da kam ich auf die Idee, dort Nextcloud zu installieren mit dem Hintergedanken, dass sich die höheren Kosten so vielleicht amortisieren wĂŒrden. Könnte sich als Schnapsidee herausstellen


Hallo

Da NextCloud Collaboration bedeutet wuerde ich folgendes empfehlen:

Am besten einfach PROTON nutzen, denn NextCloud ist fĂŒr Collaboration.

PROTON ist file, email, calender, etc. gibt es auch um sonst
. (free)

NextCloud zu nutzen ist daher eher ĂŒber das Ziel hinaus geschossen.

Sorry aber macht auch das eigene Leben einfacher. Bitte nur als Hilfe verstehen, Nicht als Werbung :slight_smile:

LG

Michael

OFF TOPIC (bitte klicken)

Das war der Grund fĂŒr mich, Manitu den RĂŒcken zu kehren. Ich hab nen gĂŒnstigen, lokalen (Mail&Web)Hoster fĂŒr mich gefunden, der die bisherigen Manitu-Preise noch etwas unterbietet, sehr zuverlĂ€ssig ist und dabei sehr guten Support bietet. Ich hatte mit dem noch keine Probleme.

Zwischenstand: neue Subdomain angelegt, neue Nextcloud mit neuer Datenbank installiert, Fehler tritt weiterhin auf.

Ich habe das an den Manitu-Support gemeldet. In deren Testumgebung sei der Fehler nicht reproduzierbar, aber sie wollen versuchen, unter meinem Account eine Testumgebung einzurichten. Dazu gibt es noch kein Ergebnis.

1 Like