Nextcloud Sicherheits- & Einrichtungswarnungen beheben

[Fireball]

Hey Patty92... danke für den Tipp. Leider brachte er keinen direkten Erfolg, aber ich wurde auf die Richtige Spur gelenkt.

Das Löschen hat nichts gebracht, anscheinend hatte ich irgendwelche Veränderungen an der Datei vorgenommen.

Ich habe mir dann einfach die entsprechende Zeile gesucht und den Eintrag selber ergänzt.

[sunpower]

On 3/22/2023 at 6:58 AM, Patty92 said:

Nutzt du den Container von lscr.io/linuxserver ?

Da kam später nochmal ein Update raus in dem unter "/config/nginx/site-confs/" die default.conf aktualisiert wurde.

 

In den Container logs siehst du dann:

 old date         │  new date   │ path
│ 2022-08-20 │ 2023-03-21 │/config/nginx/site-confs/default.conf

 

Sollttest du die "default.conf" nicht angepasst haben, kannst du:

- Container beenden

- default.conf löschen

- Container starten

 

Im Nachgang wird auf Basis der "default.conf.sample" die Datei neu angelegt.

Stehe vor dem gleichen problem wie @Fireball.

 

Ja, ich nutze den Container von "lscr.io/linuxserver".

 

Leider finde ich das hier genannte Unterverzeichnis "/config/nginx/site-confs/default.conf" nicht. Suche bisher erfolglos im Terminal mittels mc (Midnight Commander). In welchem "Stamm"-Verzeichnis muss ich starten, um in das gewünschte Unterverzeichnis zu gelangen?

Edited March 25, 2023 by sunpower

[Patty92]

44 minutes ago, sunpower said:

Ja, ich nutze den Container von "lscr.io/linuxserver".

Muss auf der gleichen Ebene sein, wie dein Verzeichnis der proxy-confs

 

 

[sunpower]

@Patty92Danke für deine Antwort. Entweder ist meine Verzeichnisstruktur anders aufgebaut oder ich bin zu sehr Linux-Noob um das richtige Verzeichnis zu finden. Unter "/mnt/Cache/appdata" sehe ich bei mir kein swag-Verzeichnis. (siehe  Screenshot)

 

Na ja, jedenfalls läuft NC 26 einwandfrei. Den Warnhinweis sehe ich ja nur, wenn ich die Admineinstellungen von NC aufrufe. Vielleicht wird bei weiteren Updates der Fehler beseitigt.

 

Edited March 26, 2023 by sunpower

[Patty92]

3 hours ago, sunpower said:

oder ich bin zu sehr Linux-Noob um das richtige Verzeichnis zu finden.

Nein, das geht auf meine Kappe, ich habe mich gestern vertan auf die Schnelle 🤦🏼 sorry. Gemeint ist natürlich das nextcloud Verzeichnis.

 

/mnt/cache/appdata/nextcloud/config/nginx/site-confs

 

In dem Verzeichnis gibt es die „default.conf“ und die „default.conf.sample“ .. die sample wurde durch das Update aktualisiert. Wenn du den Container beendest, die „default.conf“ löschst und den Container neu startest wird die Datei auf Basis der sample Datei neu aufgebaut und dann sollten auch die Fehler weg sein. ☺️

Edited March 26, 2023 by Patty92

[sunpower]

@Patty92 Wie du den beiden angehängten Screenshots entnehmen kannst, habe ich die Default.conf mit älterem Datum gelöscht, aber nach Container Neustart eine neue default.conf vorgefunden mit aktuellem Datum plus die default.conf.sample.

Leider kann ich jetzt auf Nextcloud gar nicht zugreifen, obwohl der NC-Container in Unraid als gestartet angezeigt wird.😮

 

Der Zugriff weder auf Dashbord per WebUI noch per Caldav/Cardav möglich - weder von Windows noch per Android. Das lief bisher seit Monaten einwandfrei! Ordnersynchronisationen funktionieren auch nict mehr.

 

Gibt es eine sichere "Schnellreparatur" oder muss ich Nextcloud komplett neu installieren?

Edited March 26, 2023 by sunpower

[sunpower]

Ergänzung zum vorgehenden Post:

Da ich nicht deinen korrigierten Pfad zu 100% identisch gefunden habe, bin ich "mittendrin einen anderen Weg gegangen - herausgefunden durch suchen.

[Patty92]

Um den Beitrag hier nicht zu überfluten, erstmal weiter per DM.

[sunpower]

16 hours ago, Patty92 said:

Um den Beitrag hier nicht zu überfluten, erstmal weiter per DM.

Danke für deine Zeit und Mühe mir zu helfen.👍

 

Da ich auch heute morgen leider erfolglos diverse "Reparaturmaßnahmen" versucht habe, habe ich nun doch den radikalen Weg gewählt und (nach vorheriger De-Installation) Nextcloud komplett neu installiert. Jetzt läuft Version 26 auf Anhieb ohne den Warnhinweismit "X-Robots-Tag....".

Edited March 27, 2023 by sunpower

[mgutt]

Wenn man mehrere Dateien mit dem Browser hochlädt dann zerlegt Nextcloud diese in 10MB Pakete und zeigt keine Datei an, solange nicht der komplette Upload durch ist. Kann man dieses Verhalten irgendwie ändern? Also dass er bereits hochgeladene Dateien bereits anzeigt, auch wenn der komplette Upload noch nicht durch ist? Oder vielleicht dieses "Zerhacken" komplett abschalten?!

 

EDIT: OK etwas gefunden. Nur verstehe ich nicht. Was macht denn das Kommando? Fügt das eine neue Einstellung in der config.php hinzu oder wo schreibt der die Einstellung hin?!

https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/big_file_upload_configuration.html#adjust-chunk-size-on-nextcloud-side

sudo -u www-data php occ config:app:set files max_chunk_size --value 20971520

 

 

EDIT: das hier muss ich dann bestimmt auch machen:

 

 

 

[sonic6]

On 1/16/2023 at 12:47 AM, mgutt said:

Problem: Alle meine User haben ein unendliches Kontingent. Vom Gefühl her würde ich sagen, dass man lieber einen festen Wert eintragen sollte, damit der Papierkorb nicht immer weiter wächst.

 

Zusätzlich dachte ich daran, das hier zu machen:

'trashbin_retention_obligation' => 'auto,30',

https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/trashbin_configuration.html

 

Das sollte denke ich bedeuten: Lösche, wenn der Papierkorb mehr als 50% des Kontingents belegt und grundsätzlich alles was länger als 30 Tage im Papierkorb ist.

 

 

Bin vor ein paar Jahren auf genau die gleiche "Problematik" gestoßen.

Bin das Problem letztendlich genauso angegangen wie du. Ich habe ein Default Contingent von 20GB gewählt.

300GB ist für mein System zu viel, da mein Cache nur 500GB sind und ich als Hauptnutzer bisher "nur" 10GB in der NC nutze.

Der Papierkorb ist bei mir dann nochmal so ne Art "Fallback", falls ich mal was lösche, habe den also bei mir auf "120, auto" stehen.

[sonic6]

14 hours ago, mgutt said:

EDIT: OK etwas gefunden. Nur verstehe ich nicht. Was macht denn das Kommando? Fügt das eine neue Einstellung in der config.php hinzu oder wo schreibt der die Einstellung hin?!

https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/big_file_upload_configuration.html#adjust-chunk-size-on-nextcloud-side

sudo -u www-data php occ config:app:set files max_chunk_size --value 20971520

Kann es sein, dass sich das nur auf die App/Anwendung bezieht?

Die Chunks sollen ja normalerweise "nur" 10MB groß sein. Zusammen mit dem CF-Tunnel gibt es mit NC über den Browser aber immer Probleme, da der CF-Tunnel nur 200MB Pakete zulässt.

Die NC Apps über Android/Windows machten hier nie Probleme, Up-/Download hingegen über den Browser brachen nach 200MB aber immer ab.

[mgutt]

Also ein Kumpel hatte per Browser hochgeladen und da wurde in 10 MB Pakete geteilt und es gab nur Probleme. Ich sag mal 80% der Dateien wurden nicht hochgeladen, weil Nextcloud am Ende den "Fehler beim Zusammenführen der Teile (Chunks)" zurückgab:

[mgutt]

Ich habe nun die Chunk-Size auf 512MB erhöht:

 

root@thoth:~# docker exec --user 99 nextcloud php occ config:app:set files max_chunk_size --value 512000000
Config value max_chunk_size for app files set to 512000000

 

Dieser Wert wird nicht in die config.php geschrieben, sondern in die Datenbank:

 

Außerdem habe ich die zwei Variablen gesetzt, damit PHP mehr RAM nutzen kann und die Dateigröße keine Rolle mehr spielt:

 

In NPM habe ich den Proxy Host bearbeitet und unter Advanced folgendes eingetragen:

location / {
  add_header Strict-Transport-Security "max-age=15552000; includeSubdomains; preload;";
  client_max_body_size 32G;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection $http_connection;
  proxy_http_version 1.1;
  include conf.d/include/proxy.conf;
}

 

Also die neue Zeile ist diese:

  client_max_body_size 32G;

 

Außerdem habe ich die max execution time von PHP auf 2 Stunden verlängert, wobei ich nicht glaube, dass das relevant ist (Standard bei Nextcloud ist 1 Stunde). Auch habe ich das Apache Limit entfernt, was standardmäßig auf 1024MB eingestellt ist.

 

Dazu habe ich einfach meinen stündlichen Cronjob erweitert, den Nextcloud ja sowieso benötigt:

#!/bin/bash

# make script race condition safe
if [[ -d "/tmp/${0//\//_}" ]] || ! mkdir "/tmp/${0//\//_}"; then echo "Script is already running!" && exit 1; fi; trap 'rmdir "/tmp/${0//\//_}"' EXIT;

# add custom php settings
htaccess_file="/mnt/cache/appdata/nextcloud/html/.htaccess"
if [[ -f "$htaccess_file" ]]; then
  if ! grep "max_input_time" "$htaccess_file" &>/dev/null; then
    echo "
# Custom PHP Settings
php_value max_input_time 7200
php_value max_execution_time 7200

# Custom Apache Settings
LimitRequestBody 0
" >> "$htaccess_file"
    echo ".htaccess updated."
  else
    echo ".htaccess already up-to-date."
  fi
else
  echo "Error: .htaccess not found."
fi

# execute cron
docker exec -u 99 nextcloud php -f /var/www/html/cron.php

 

Die Änderungen sind alle über "System" sichtbar:

 

 

[mgutt]

Ich habe etwas Interessantes herausgefunden. Ich habe das Chunking deaktiviert, weil mein User nach wie vor Upload-Probleme hatte.

 

Dann habe ich es mit der lokalen Nextcloud-IP ebenfalls ausprobiert (also ohne Proxy) und stieß auf das selbe Problem. In der nextcloud.log tauchte dieser Fehler auf:

 

"method":"PUT",
"url":"/remote.php/webdav/xxx/xxx.mkv",
"message":"Erwartete Dateigr\u00f6\u00dfe von 1207907122 bytes, aber 0 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.",

 

Schlussendlich stellte sich heraus, dass der Apache Webserver im Nextcloud-Container auch noch ein Limit von 1024MB besaß. Die Anpassung von "LimitRequestBody" auf "0" hat es dann gelöst. Im vorherigen Post habe ich den Code entsprechend aktualisiert.

 

Ich probiere jetzt erstmal ob es damit grundsätzlich geht. Danach werde ich aber auch noch mal mit dem Chunking von 512MB probieren. Macht eigentlich keinen Sinn, aber vielleicht schlägt das Chunking ja manchmal fehl und er trifft dann auf das Apache Limit?!

[mgutt]

Welchen Sinn hat dieses Chunking eigentlich? Nachdem wir nun fehlerfrei in meine Cloud ohne Chunking hochladen können, haben wir heute testweise Chunking mit 512MB wieder aktiviert. Dann habe ich eine Datei hochgeladen und den Browser geschlossen. Ich dachte nun, dass der dann beim Upload einfach weiter macht, aber der fängt immer bei Null an:

 

 

Irgendwann löscht Nextcloud dann automatisch veraltete Chunks. Oder nutzt der die Chunks nur bei der Nutzung der App für das Fortsetzen?

 

EDIT: Ja, diese Funktion existiert aktuell nur in den Apps:

https://github.com/nextcloud/server/issues/673

Quote

It is implemented on all clients, but not on web.

 

Übrigens war das standardmäßige Chunking von 10MB der Grund dafür, dass ich lokal so lahm hochladen konnte. Jetzt wo ich es auf 512MB hochgesetzt habe, kann ich im Browser die Pausen zwischen den Chunks beim Upload-Balken sogar sehen. Die waren wohl bei 10MB quasi permanent aktiv, was den Upload so stark ausbremste.

 

EDIT2: Mit 512MB Chunking hat mein User jetzt auch keine Probleme mehr. Ich habe daher nun den Wert auf 64 MiB geändert:

docker exec --user 99 nextcloud php occ config:app:set files max_chunk_size --value 67108864

 

Das ist denke ich ein Wert, der den Apps noch ein sinnvolles Fortsetzen erlaubt und parallel lokal die Cloud nicht zu stark ausbremst.

 

Die schlussendlich Ursache des Problems sehe ich übrigens beim Apache und der fehlenden "LimitRequestBody" Einstellung. Ich vermute, dass Safari irgendwann das Chunking nicht mehr respektiert hat und dann ins Limit vom Apache gelaufen ist. Das erklärt auch, warum so viele Probleme haben, wenn ihre Nextcloud über den Cloudflare Proxy betrieben wird (der trennt meine ich bei 128MB).

 

Mal sehen ob ich bei Github einen Pull Request dafür abgesetzt bekomme. Ansonsten mache ich zumindest ein Issue dafür auf.

 

EDIT3: Erledigt: https://github.com/nextcloud/server/issues/37695

[mgutt]

Habt ihr auch das Problem?

https://help.nextcloud.com/t/how-to-hide-left-menu-in-files-app-on-25-x/159617

 

Das ist ja richtig ätzend. Wäre ich lieber bei Version 24 geblieben.

 

Man sieht halt einfach gar nichts:

 

[i-B4se]

@mgutt

Bei mir habe ich nichts am Chunking etc. geändert und kann ohne Probleme große Dateien hochladen.

Ich lade gerade eine 25GB Datei hoch und das mit dem maximum vom Array. 

Wo kann ich das mit dem Chunking sehen?

 

Auch kann ich die Cloud mit dem Handy (iPhone 14 Pro Max) ganz normal sehen.

Bei mir schiebt sich das Menü nicht so davor.

 

Ich habe die Version 26.0.0

[mgutt]

1 hour ago, i-B4se said:

Ich lade gerade eine 25GB Datei hoch und das mit dem maximum vom Array. 

Ich kann jetzt mit 10G hochladen, weil RAM Caching ja auch noch boostet.

 

1 hour ago, i-B4se said:

Wo kann ich das mit dem Chunking sehen?

Mit dem Befehl während dem Upload:

 

find /mnt/user/appdata/nextcloud/data/*/uploads -type f -exec ls -lah {} \;

 

Ich kann jedem nur empfehlen auf zumindest 64 MiB zu erhöhen. Deutlich weniger Chunking und damit mehr Performance.

 

1 hour ago, i-B4se said:

kann ohne Probleme große Dateien hochladen.

Kann ich und 10 andere auch, aber eben einer mit dem Safari nicht immer. Der hatte zufällig Probleme. Und er ist damit nicht alleine wenn man nach der Fehlermeldung googlet. 

[sonic6]

On 4/12/2023 at 9:17 PM, mgutt said:

Das erklärt auch, warum so viele Probleme haben, wenn ihre Nextcloud über den Cloudflare Proxy betrieben wird (der trennt meine ich bei 128MB).

sollten ca 200MB sein

 

19 hours ago, mgutt said:

 

21 hours ago, i-B4se said:

Wo kann ich das mit dem Chunking sehen?

Mit dem Befehl während dem Upload:

 

find /mnt/user/appdata/nextcloud/data/*/uploads -type f -exec ls -lah {} \;

 

Ich kann jedem nur empfehlen auf zumindest 64 MiB zu erhöhen. Deutlich weniger Chunking und damit mehr Performance.

ich hatte, abgesehen vom CF Tunnel auch noch nie Probleme damit. Kann es vielleicht sein, dass das Chunking beim LSIO Container im Web default aus ist?

[mgutt]

7 hours ago, sonic6 said:

dass das Chunking beim LSIO Container im Web default aus ist?

Kommando steht in meinem vorherigen Beitrag 😁

 

Besagter Kumpel hat jetzt übrigens auf einen Firefox Container gewechselt. Da lief der Upload, aber trotzdem kamen eine Reihe "Es ist ein unbekannter Fehler aufgetreten":

 

On 4/13/2023 at 4:28 PM, i-B4se said:

Auch kann ich die Cloud mit dem Handy (iPhone 14 Pro Max) ganz normal sehen.

Lag übrigens an einer alten Chrome Version für Android. Die aktuelle hat das Problem nicht. Ich nutzte noch eine sehr alte, weil ich die neuen Tab-Gruppen von Chrome hasse wie die Pest. Muss ich aber wohl jetzt schlussendlich mit leben. 😑

[sonic6]

16 hours ago, mgutt said:

Kommando steht in meinem vorherigen Beitrag 😁

funktioniert nicht mit dem LSIO Container. Weder mit Web noch App uploads.

 

root@Unraid-1:~# find /mnt/user/appdata/nextcloud/data/*/uploads -type f -exec ls -lah {} \;
find: ‘/mnt/user/appdata/nextcloud/data/*/uploads’: No such file or directory

 

[mgutt]

Naja, der Pfad existiert nicht. Steht ja da. Mussr du schon an deinen appdata Pfad anpassen.

[sonic6]

On 4/13/2023 at 6:02 PM, mgutt said:

Mit dem Befehl während dem Upload:

 

find /mnt/user/appdata/nextcloud/data/*/uploads -type f -exec ls -lah {} \;

 

Ich kann jedem nur empfehlen auf zumindest 64 MiB zu erhöhen. Deutlich weniger Chunking und damit mehr Performance.

 

Also falls es jemand mit dem LSIO Container Testen will:

 

find /mnt/user/nextcloud/*/uploads -type f -exec ls -lah {} \;

 

Mir ist aufgefallen, dass das Chunking hier bei 10MB aus dem Webbrowser lag, jedoch über die Windows Anwendung folgendes zeigt:

root@Unraid-1:~# find /mnt/user/nextcloud/*/uploads -type f -exec ls -lah {} \;
-rw-r--r-- 1 nobody users 9.6M Apr 16 09:58 /mnt/user/nextcloud/sonic6/uploads/995972344/0000000000000000
-rw-r--r-- 1 nobody users 570M Apr 16 09:58 /mnt/user/nextcloud/sonic6/uploads/995972344/0000000000000001
-rw-r--r-- 1 nobody users 953M Apr 16 09:59 /mnt/user/nextcloud/sonic6/uploads/995972344/0000000000000002
-rw-r--r-- 1 nobody users 954M Apr 16 10:00 /mnt/user/nextcloud/sonic6/uploads/995972344/0000000000000003
-rw-r--r-- 1 nobody users 954M Apr 16 10:00 /mnt/user/nextcloud/sonic6/uploads/995972344/0000000000000004
-rw-r--r-- 1 nobody users 954M Apr 16 10:01 /mnt/user/nextcloud/sonic6/uploads/995972344/0000000000000005
-rw-r--r-- 1 nobody users 954M Apr 16 10:02 /mnt/user/nextcloud/sonic6/uploads/995972344/0000000000000006

Hier scheint die Größe der Chunks bei ca 1GB zu liegen.

Wenn man das noch anpassen könnte und sich das auch aufs WebDAV auswirken würde, wäre der CF-Tunnel wieder eine Option für die NC.

[mgutt]

1 minute ago, sonic6 said:

Mir ist aufgefallen, dass das Chunking hier bei 10MB aus dem Webbrowser lag, jedoch über die Windows Anwendung folgendes zeigt:

Also wenn du was über den Browser hochlädst, siehst du in dem Ordner 10MB Chunks und sonst 1GB? Das macht ja Sinn, wo es nur eine Chunk-Einstellung in Nextcloud gibt ^^