mgutt

Yes, but be aware of a bug, which causes re-spawning the existing copy/move rsync. This will be solved In Unraid 7.3 as of these bug fixes: https://github.com/unraid/webgui/pull/2429#issuecomment-3448927951

Ist noch nicht von Limetech angenommen worden, aber wenn dann wird der Upload über die WebGUI deutlich schneller: GitHubOptimize file upload performance and fix estimated upload...Remove Base64 encoding overhead (33% size reduction) Increase chunk size from 2MB to 20MB Implement raw binary upload via XMLHttpRequest Add X-CSRF-Token header support in local_prepend.php Fix upl...

FYI: I'm working on these features: GitHubFix #2500: File Manager UI/UX improvements by mgutt · Pul...This PR addresses multiple issues and feature requests: Fix PR fix: update HTML structure in Templates.php to improve formatting and… #2402 Markdown Parser regression (literal colon bug): Changed...

I solved this and it will be part of Unraid 7.4 The reason was that rsync returns two totally different progress states, depending if a file transfer is running or currently finished. And with a huge amount of small files, it even NEVER returns the progress values. The solution was to calculate it, if rsync does not return it. In addition I added a hysteresis to smoothen the progress a little bit: https://github.com/unraid/webgui/pull/2429/commits/6a4ec6ee3e236f4c1379e8b2d5658ad9249d1fba

Wenn du per WebGUI Download nur 40 MB/s schaffst, hast du für 1 Gbit/s schon mal locker 60 MB/s zu wenig. Hast du von einer SSD oder HDD heruntergeladen? Die Upload-Geschwindigkeit der WebGUI ist eher schlecht. Ich glaube weil die in zu kleinen Chunks hochlädt. Das untersuche ich die Tage mal und baue es dann um. Ist mir selbst schon negativ aufgefallen. Allerdings sind deine 9 KB/s auch hier viel zu wenig. So lahm ist Unraid dann doch nicht. Ich schaffe auf die NVMe eines Servers, der mit 1G angebunden ist, immerhin 170 KB/s: Allerdings ist die Anzeige falsch, denn laut Stoppuhr sind es eher 25 MB/s. Hattest du wie ich gebeten habe direkt auf oder von /cache geladen? Du kannst auch gerne mal parallel das Terminal aufmachen und das hier laufen lassen: top -cEventuell erkennst du eine sehr hohe CPU-Last während dem Upload? Auch ein sehr schlechtes Signal ist eine hohe Zahl bei "wa": D.h. die CPU muss auf etwas warten zB eine Disk.

Das sind recht magere Infos. Fragen: reden wir von einem Upload oder einem Download? gilt es für beide Richtungen? gilt das für Dateien, die aktuell auf der NVMe liegen? welche Download-Geschwindigkeit erreichst du über die WebGUI* *Anmerkungen zum WebGUI Download. Bitte achte darauf, dass du NICHT über einen User Share lädst, sondern die Cache Disk direkt öffnest, also hier oben der Cache Pfad steht. Dann einfach im Browser die Download-Geschwindigkeit prüfen: Je nachdem was du da erreichst, können wir dann überlegen, wo wir mit der Analyse weitermachen.

Die diagnostics enthält nicht das letzte Log, sondern nur das aktuelle. Also nicht das wo der Server crashte, sondern wo er gerade fehlerfrei läuft. Daher ist keine Analyse möglich (wenn nicht zufällig andere Fehler drin wären, ich sehe aber soweit nichts). Aktiviere die Speicherung der Logs auf dem USB Stick und installiere das Skript: https://forums.unraid.net/topic/121039-syslog-notify-create-notifications-if-specific-words-occur-in-the-logs/ Wenn die Logs auf dem Stick geschrieben werden, liegen sie dort in /logs als syslog und syslog-previous. Ich meine sie kommen dann auch automatisch in der das Diagnostics ZIP mit rein. Bin ich aber gerade nicht sicher. EDIT: Die ganzen Lesefehler sind böse. Ich hoffe du hast Backups oder es sind keine wichtigen Daten auf Disk 1. Die ist vermutlich hinüber.

This is not possible. You need to export the nextcloud database to sql as root user (execute this inside the container terminal): mariadb-dump -u root -p --single-transaction --routines --events --triggers nextcloud >/var/lib/mysql/nextcloud.$(date +"%F-%H-%M-%S").sql Now stop the mariadb container and rename the appdata path through the file manager or through the unraid terminal: mv /mnt/user/appdata/mariadb /mnt/user/appdata/mariadb_old Now select the add container button on the docker page, select your mariadb template from the drop-down and do this: Change the name e.g. nextcloud-mariadb (important) Change the repository name to mariadb:11.8 Press OK to install it. Now, check the logs and copy the new root password. Copy the nextcloud.sql file through the file manager or unraid terminal as follows: cp -a /mnt/user/appdata/mariadb_old/data/nextcloud*.sql /mnt/user/app data/mariadb/data/nextcloud.sql Open the mariadb container and import the database as follows: mariadb -u root -p nextcloud < /var/lib/mysql/nextcloud.sql I did this by myself a few weeks ago. My database is currently fixed to version 11.4 because of that: A possible alternative to those commands is to install phpmyadmin or a similar db webgui. Or use HeidiSQL if you prefer an app.

Maybe useful for others. This sets a bandwidth limit for nextcloud downloads (added through the advanced tab of the host settings): # main rules adopted from nginx proxy manager location / { add_header Strict-Transport-Security "max-age=15552000; includeSubdomains; preload;"; client_body_buffer_size 512k; client_max_body_size 32G; proxy_request_buffering off; proxy_read_timeout 600s; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $http_connection; proxy_http_version 1.1; # Proxy! include conf.d/include/proxy.conf; } # bandwith limit for downloads location ~ ^/(public\.php/dav/files|remote\.php/dav/files)/ { # ignore X-Accel-Buffering header (https://github.com/nextcloud/server/pull/25747) proxy_ignore_headers X-Accel-Buffering; # limit to 10 Mbit/s limit_rate 1280k; # make sure proxy buffering is enabled proxy_buffering on; # disable buffering to temporary files proxy_max_temp_file_size 0; # general proxy settings add_header Strict-Transport-Security "max-age=15552000; includeSubdomains; preload;"; client_body_buffer_size 512k; client_max_body_size 32G; proxy_request_buffering off; proxy_read_timeout 600s; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $http_connection; proxy_http_version 1.1; include conf.d/include/proxy.conf; } location /.well-known/carddav { return 301 /remote.php/dav/; } location /.well-known/caldav { return 301 /remote.php/dav/; }

Ich habe nun folgende "Advanced" Einstellung im Nginx Proxy Manager hinterlegt, um Datei-Downloads auf 10 MBit/s zu begrenzen: # main rules adopted from nginx proxy manager location / { add_header Strict-Transport-Security "max-age=15552000; includeSubdomains; preload;"; client_body_buffer_size 512k; client_max_body_size 32G; proxy_request_buffering off; proxy_read_timeout 600s; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $http_connection; proxy_http_version 1.1; # Proxy! include conf.d/include/proxy.conf; } # bandwith limit for downloads location ~ ^/(public\.php/dav/files|remote\.php/dav/files)/ { # ignore X-Accel-Buffering header (https://github.com/nextcloud/server/pull/25747) proxy_ignore_headers X-Accel-Buffering; # limit to 10 Mbit/s limit_rate 1280k; # make sure proxy buffering is enabled proxy_buffering on; # disable buffering to temporary files proxy_max_temp_file_size 0; # general proxy settings add_header Strict-Transport-Security "max-age=15552000; includeSubdomains; preload;"; client_body_buffer_size 512k; client_max_body_size 32G; proxy_request_buffering off; proxy_read_timeout 600s; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $http_connection; proxy_http_version 1.1; include conf.d/include/proxy.conf; } location /.well-known/carddav { return 301 /remote.php/dav/; } location /.well-known/caldav { return 301 /remote.php/dav/; } Es hat eine ganze Weile gedauert, bis ich darauf gekommen bin, dass Nextcloud einen Header setzt, der das Buffering von Nginx deaktiviert: GitHubAdd X-Accel-Buffering by default for downloads · Issue #2...Nextcloud installations behind a nginx reverse proxy are known to abort downloads larger than 1GB: https://www.reddit.com/r/NextCloud/comments/ayhlji/unable_to_download_files_larger_than_1gb/ Setti... Keine Ahnung warum dieser "Fix" angenommen wurde, denn man hätte einfach nur die proxy_max_temp_file_size Einstellung anpassen müssen, um Dateien größer als 1GB herunterladen zu können. Jedenfalls läuft das gut und Nextcloud-Downloads überlasten nicht mehr meine Internetleitung. Die Upload-Statistik der Fritz!Box bestätigt dies: Hinweis: Das gilt pro HTTP Verbindung. Mehrere Downloads nutzen also JEWEILS 10 Mbit/s. Ein globales Limit ist deutlich anspruchsvoller, brauchte ich jetzt aber auch nicht.

This is not normal. Check your syslog. The block diagram of the board looks pretty normal (not additional controllers visible). So maybe something related to the ASMedia card?!

You need to explicity set C State Limit to C10. "auto" often means "disabled".

I would upload the whole file and let the chat do the work for you. If you don't want any server details in the log: Search and Replace all relevant strings with an editor like VSCode.

I never tested IPv6, but why do you need it? I mean, are you using Plex without Reverse Proxy?!

I don't think that the database is relevant in this context. I would enable all debug logs. You can enable them in the GUI. Then start a failing movie and extract the logs. Then clean the logs and start a good movie. Now let chatgpt/gemini analyze them.

Create slow.cnf in your config directory: [mysqld] slow_query_log = 1 slow_query_log_file = /var/lib/mysql/slow.log long_query_time = 2 log_output = FILE Change perms: chmod -v "0600" /mnt/user/appdata/*mariadb*/config/slow.cnf Stop web containers using mariadb. Restart mariadb container. Start web containers. Check if any queries are logged (the slow.log file will be created even if no slow query has been captured by now).

Er will damit sagen, dass das Array mit seiner Parität kein Backup ist, sondern nur ein Komfortmerkmal. Backups gehören auf externe Datenträger, Backup-Server, etc. Und ja, du kannst von DiskX nach DiskY kopieren. Dauert aber länger als auf eine externe Platte, wegen parallelem Lesen/Schreiben innerhalb des Arrays + laufende Emulation.

syslog to flash aktivieren und evtl noch das Skript: https://forums.unraid.net/topic/121039-syslog-notify-create-notifications-if-specific-words-occur-in-the-logs/

Hast du was in der /boot/config/go File stehen, dass evtl mit 7.2 inkompatibel ist?

Ja und nein. Unraid emuliert das fehlende Drive mit Hilfe der anderen Drives. Das ist der Sinn an einem Drive-Verbund, der über eine Parität abgesichert ist. Das ist keine Eigenheit von Unraid, sondern gilt auch für alle RAIDs. Dh das System soll genauso weiter arbeiten als wäre das Drive da. Im Umkehrschluss heißt das aber auch, dass das Betriebssystem keine Rücksicht auf das physische Fehlen eines Drives nimmt und weiter Daten so verteilt, als wäre es da. Es bleibt dem User überlassen das Problem zu beheben: Austausch des Drives alle Daten von dem emulierten Drive runterholen (leeren) und abschließend aus dem Array entfernen (New Config) Und nur damit das klar ist: Geht noch eine Drive kaputt sind alle Daten von Disk4 verloren.

Ich kann dir nur empfehlen niemals auf ein Unraid X.X.0 zu aktualisieren, außer man kann damit leben doch mal zurückzurollen und will aktiv helfen. Die Version "hält" jedenfalls nie länger als ein paar Tage 😄 Auch .1 ist in der Regel schnell wieder Geschichte. So vom Gefühl läuft es so: bis zum RC geht vieles durch beim Release von .0 werden von viel mehr Usern kritische Problem entdeckt: Zeitnah kommt .1 danach macht man sich an die Behebung weniger kritischer Probleme: .2 kommt Übrigens sollte jedem klar sein, dass Limetech hier nicht mitliest. Also wenn gehört sowas hier hin: https://forums.unraid.net/bug-reports/stable-releases/

Die Frage verstehe ich auch nicht. Du solltest ganz normal auf alle Daten von Disk1 zugreifen können. Dass Daten da sind, sieht man ja auch an der Belegung. Weißt du nicht, wie du den Inhalt einer Disk anschauen kannst (Icon ganz links) oder wieso stellst du dir die Frage?

Dein Shutdown-Start laut Log: Sep 27 11:12:05 Datenlager shutdown[1564799]: shutting down for system haltund die letzten Log-Einträge dazu: Sep 27 11:13:18 Datenlager rc.acpid: Stopping ACPI power management daemon... Sep 27 11:13:18 Datenlager rc.acpid: kill 1621 Sep 27 11:13:18 Datenlager rc.acpid: killall --ns 1568616 acpid Sep 27 11:13:18 Datenlager acpid: exiting Sep 27 11:13:18 Datenlager rc.acpid: ACPI power management daemon... Stopped. Sep 27 11:13:18 Datenlager rc.udev: Stopping udevd Sep 27 11:13:18 Datenlager rc.0: Sending all processes the SIGTERM signal. Sep 27 11:13:18 Datenlager rc.0: /sbin/killall5 -15 Mein Server: Nov 2 00:55:23 atum shutdown[47575]: shutting down for system haltNov 2 00:55:34 atum rc.acpid: Stopping ACPI power management daemon... Nov 2 00:55:34 atum rc.acpid: kill 1753 Nov 2 00:55:34 atum rc.acpid: killall --ns 49927 acpid Nov 2 00:55:35 atum rc.acpid: ACPI power management daemon... Failed. Nov 2 00:55:35 atum rc.udev: Stopping udevd Nov 2 00:55:35 atum acpid: exiting Nov 2 00:55:35 atum rc.0: Sending all processes the SIGTERM signal. Nov 2 00:55:35 atum rc.0: /sbin/killall5 -15 Bis hier hin sind also deine Logs normal. Dann habe ich mich aber gefragt, wo eigentlich der Rest ist. Und tatsächlich fehlt da einiges, denn nach dem killall folgen noch einige Commands im rc.0 Skript: # Kill all remaining processes (including rsyslogd) OMITPIDS="$(for P in $(/usr/bin/pgrep mdmon); do /bin/echo -o $P; done)" # Don't kill mdmon if [[ $1 != fast ]]; then log "Sending all processes the SIGTERM signal." run /sbin/killall5 -15 $OMITPIDS /bin/sleep 5 log "Sending all processes the SIGKILL signal." run /sbin/killall5 -9 $OMITPIDS fi # limetech - let's keep this on the USB flash # Carry a random seed between reboots. /usr/sbin/seedrng /bin/cp -f /var/lib/seedrng/seed.credit /boot/config/random-seed 2>/dev/null # If "Mirror syslog to flash" is disabled and "Copy" is enabled (default) then copy current syslog to flash # The copied file will become /boot/logs/syslog-previous after next boot (see rc.M) # Safety feature: copy only when enough space is available on the flash device CFG=/boot/config/rsyslog.cfg [[ -r $CFG ]] && MIRROR=$(/bin/grep -Pom1 '^syslog_flash="\K[^"]+' $CFG) [[ -r $CFG ]] && COPY=$(/bin/grep -Pom1 '^syslog_shutdown="\K[^"]+' $CFG) if [[ ! -f /boot/logs/syslog && -z $MIRROR && -z $COPY ]]; then AVAIL=$(/bin/df --output=avail /boot | /bin/awk '(NR>1){print $1*1024;exit}') SIZE=$(($(/bin/stat -c%s /var/log/syslog)*2)) if [[ $AVAIL -ge $SIZE ]]; then log "Saving syslog to flash" /bin/cp -f /var/log/syslog /boot/logs/syslog fi fi # Before unmounting file systems write a reboot or halt record to wtmp. /sbin/$SHUTDOWN_COMMAND -w # Turn off swap: if [[ ! $(/bin/cat /proc/swaps | /bin/wc -l) == 1 ]]; then log "Turning off swap." run /sbin/swapoff -a run /bin/sync fi # Unmount local file systems: # limetech - but not /, /lib, /usr or /boot (yet) log "Unmounting local file systems:" EXCLUDE_TYPES=("proc" "sysfs" "tmpfs" "devtmpfs" "devpts" "nfsd") EXCLUDE_PATHS=("/" "/lib" "/usr" "/boot") while IFS= read -r LINE; do MOUNT_TYPE=$(/bin/echo "$LINE" | awk '{print $3}') MOUNT_PATH=$(/bin/echo "$LINE" | awk '{print $2}') [[ " ${EXCLUDE_TYPES[@]} " =~ " $MOUNT_TYPE " ]] && continue [[ " ${EXCLUDE_PATHS[@]} " =~ " $MOUNT_PATH " ]] && continue run /bin/umount -v "$MOUNT_PATH" done <<< "$(/bin/cat /proc/mounts)" # Update PATH hashes: hash -r # limetech - shut down the unraid driver if started if /bin/grep -qs 'mdState=STARTED' /proc/mdstat; then log "Stopping md/unraid driver:" /bin/echo "stop" >/proc/mdcmd if /bin/grep -qs 'mdState=STOPPED' /proc/mdstat; then log "Clean shutdown" /bin/rm -f /boot/config/forcesync else log "Unclean shutdown - Cannot stop md/unraid driver" fi fi # This never hurts: /bin/sync log "Remounting /boot read-only:" run /bin/mount -v -o remount,ro /boot log "Remounting /lib read-only:" run /bin/mount -v -o remount,ro /lib log "Remounting /usr read-only:" run /bin/mount -v -o remount,ro /usr log "Remounting root filesystem read-only:" run /bin/mount -v -n -o remount,ro / # Update PATH hashes: hash -r # sleep 3 fixes problems with some hard drives that don't # otherwise finish syncing before reboot or poweroff /bin/sleep 3 # This is to ensure all processes have completed on SMP machines: wait if [[ -x /sbin/genpowerd ]]; then # See if this is a powerfail situation: if /bin/grep -Eq "FAIL|SCRAM" /etc/upsstatus 2>/dev/null; then # Signal UPS to shut off the inverter: run /sbin/genpowerd -k if [[ $? != 0 ]]; then log "There was an error signaling the UPS." log "Perhaps you need to edit /etc/genpowerd.conf to configure" log "the serial line and UPS type." # Wasting 15 seconds of precious power: /bin/sleep 15 fi fi fi # Now halt (poweroff with APM or ACPI enabled kernels) or reboot. if [[ $SHUTDOWN_COMMAND == reboot ]]; then log "Rebooting." run /sbin/reboot else log "Powering off." run /sbin/poweroff fi Ich vermute bei dir hängt einer der unmounting Befehle. Um das zu ermitteln, brauchen wir aber mehr Logs. Mach mal bitte das über das Terminal: sed -i '/# run & log functions/a\ exec 3> >(stdbuf -oL awk -v pid="$$" '\''{ print strftime("%F %T"), "rc.0["pid"]:", $0 }'\'' >> /run/shutdown-debug.log)\ export BASH_XTRACEFD=3\ export PS4='\''+ ${BASH_SOURCE##*/}:${LINENO}: '\''\ set -x' /etc/rc.d/rc.0 sed -i '/\/bin\/sync/a\ exec 3>&-\ cp /run/shutdown-debug.log /boot/logs/shutdown-debug.log' /etc/rc.d/rc.0 Das /boot/logs/shutdown-debug.log enthält dann fast alles was das Shutdown Skript macht. Bei mir endet es dann zB so: 2025-11-02 02:49:23 rc.0[8642]: + rc.0:252: run /bin/umount -v /mnt 2025-11-02 02:49:23 rc.0[8642]: + rc.runlog:13: /usr/bin/logger -t rc.0 -- /bin/umount -v /mnt 2025-11-02 02:49:23 rc.0[8642]: + rc.runlog:15: /bin/umount -v /mnt 2025-11-02 02:49:23 rc.0[8642]: + rc.0:247: IFS= 2025-11-02 02:49:23 rc.0[8642]: + rc.0:247: read -r LINE 2025-11-02 02:49:23 rc.0[8642]: + rc.0:255: hash -r 2025-11-02 02:49:23 rc.0[8642]: + rc.0:258: /bin/grep -qs mdState=STARTED /proc/mdstat 2025-11-02 02:49:23 rc.0[8642]: + rc.0:270: /bin/sync 2025-11-02 02:49:23 rc.0[8642]: + rc.0:271: execSolltest du auch soweit (fehlerfrei) kommen, bliebe nur noch das als Fehlermöglichkeit: umount des USB-Sticks funktioniert nicht /sbin/poweroff hat keine Wirkung Lad am besten dein Shutdown Log komplett hoch.

Ja, da wird man wohl noch einige Zeit dran nachschärfen. zB doppelte Scrollbalken (außen und innen) gehen echt gar nicht: Bei den horizontalen Scrollbalken bei der Disk Übersicht würde mir jetzt spontan auch keine schickere Lösung einfallen, aber der Scrollbalken im Menü ist hässlich und sollte lieber mit in das Breadcrumb Menü wandern: Der File Editor konnte meiner Ansicht nach übrigens auch nie frei vergrößert werden.

No, read the first post.