March 17, 20251 yr Since upgrading to Unraid 7.0.0, my server keeps freezing, requiring hard reboots. After rebooting, the machine often fails to detect the flash drive until I switch USB ports, making me hesitant to reboot remotely. While traveling, it froze again but recovered after a few hours, allowing me to gather data. The Mover Tuning feature seems problematic since the update, but could there be other issues? Should I be concerned about rebooting? plugin: installing: memorystorage.plg Executing hook script: pre_plugin_checks plugin: downloading: memorystorage.plg ... done Executing hook script: pre_plugin_checks This script may take a few minutes to run, especially if you are manually mounting a remote share outside of /mnt/disks or /mnt/remotes /usr/bin/du --exclude=/mnt/user --exclude=/mnt/user0 --exclude=/mnt/disks --exclude=/proc --exclude=/sys --exclude=/var/lib/docker --exclude=/boot --exclude=/mnt -h -d2 / 2>/dev/null | grep -v 0$' ' 1.7M /.cache/mesa_shader_cache_db 1.7M /.cache 20K /tmp/tailscale 243M /tmp/.mount_firefopFevU6 4.0K /tmp/unraidcheck 132K /tmp/user.scripts 18M /tmp/fix.common.problems 27G /tmp/ca.mover.tuning 4.0K /tmp/ca_notices 36M /tmp/CA_logs 60K /tmp/gui.search 16K /tmp/unassigned.devices 4.0K /tmp/file.activity 4.0K /tmp/disklocation 14M /tmp/community.applications 160K /tmp/appdata.backup 424K /tmp/notifications 1.1M /tmp/plugins 4.0K /tmp/emhttp 27G /tmp 596M /usr/bin 28M /usr/lib 815M /usr/lib64 90M /usr/libexec 463M /usr/local 53M /usr/sbin 362M /usr/share 7.3M /usr/src 1.1M /usr/man 20K /usr/info 300K /usr/include 972K /usr/doc 2.4G /usr 24M /sbin 80K /run/libvirt 2.1M /run/docker 4.0K /run/avahi-daemon 8.0K /run/elogind 4.0K /run/dbus 4.0K /run/hook-state 628K /run/udev 16K /run/blkid 2.9M /run 12K /lib64/pkgconfig 1.8M /lib64/elogind 4.4M /lib64/security 47M /lib64 25K /lib/dhcpcd 192M /lib/firmware 18K /lib/modprobe.d 29M /lib/modules 512 /lib/systemd 8.5M /lib/udev 234M /lib 4.0K /etc/rsyslog.d 1.1M /etc/libvirt 340K /etc/libvirt- 8.0K /etc/fonts 12K /etc/gtk-3.0 40K /etc/zfs 8.0K /etc/OpenCL 4.0K /etc/pkcs11 152K /etc/lvm 8.0K /etc/libnl 8.0K /etc/ssmtp 20K /etc/samba 8.0K /etc/php.d 24K /etc/php-fpm.d 40K /etc/nginx 2.7M /etc/file 24K /etc/avahi 44K /etc/apcupsd 12K /etc/sysstat 44K /etc/security 260K /etc/ssl 568K /etc/ssh 4.0K /etc/nvme 48K /etc/mcelog 100K /etc/mc 60K /etc/logrotate.d 4.0K /etc/sensors.d 9.3M /etc/udev 28K /etc/modprobe.d 112K /etc/pam.d 12K /etc/elogind 4.0K /etc/cron.monthly 4.0K /etc/cron.hourly 20K /etc/cron.daily 4.0K /etc/cron.d 8.0K /etc/cron.weekly 8.0K /etc/dbus-1 4.0K /etc/sasl2 176K /etc/bash_completion.d 80K /etc/default 8.0K /etc/acpi 64K /etc/profile.d 116K /etc/X11 18M /etc 12M /bin 143M /var/sa 544M /var/local 4.0K /var/kerberos 16K /var/state 4.8M /var/cache 16K /var/named 16K /var/tmp 16K /var/spool 4.0K /var/lock 7.9M /var/log 4.6M /var/lib 703M /var 1.8M /root/.cache 4.0K /root/.mozilla 4.0K /root/.dbus 2.1M /root/.pm2 4.0K /root/.config 3.9M /root 30G / 0 /mnt/rootshare 0 /mnt/addons 0 /mnt Finished. NOTE: If there is any subdirectory from /mnt appearing in this list, then that means that you have (most likely) a docker app which is directly referencing a non-existant disk or cache pool script: memorystorage.plg executed Executing hook script: post_plugin_checks unraid-diagnostics-20250317-0513.zip
March 17, 20251 yr Community Expert Yep, 27G in /tmp is definitely not normal. Seems you have detailed logging enabled for mover tuning and possibly mover itself and it's filling up your memory with tons of logs. Made worse by apparently running the mover every hour. Edited March 17, 20251 yr by Kilrah
March 17, 20251 yr Author 14 minutes ago, Kilrah said: Yep, 27G in /tmp is definitely not normal. Seems you have detailed logging enabled for mover tuning and possibly mover itself and it's filling up your memory with tons of logs. Made worse by apparently running the mover every hour. Thanks. Should I be concerned about rebooting remotely? I'm only hesitant because it failed to boot up after previous freeze ups but that very well may have had to do with hard rebooting while in a frozen state. I won't be back home for another week so I don't want to reboot if it won't boot back up.
March 17, 20251 yr Author 22 minutes ago, Michael_P said: You should also fix the corruption on your NVME Hadn't seen that—thanks for pointing that out. Forgive my ignorance but how do I go about fixing this?
March 17, 20251 yr Community Expert 21 minutes ago, Ichthus said: Hadn't seen that—thanks for pointing that out. Forgive my ignorance but how do I go about fixing this? In maintenance mode, run a file system check on it (click on the drive), and follow the instructions
March 17, 20251 yr Community Expert 1 hour ago, Ichthus said: Thanks. Should I be concerned about rebooting remotely? I'm only hesitant because it failed to boot up after previous freeze ups but that very well may have had to do with hard rebooting while in a frozen state. I won't be back home for another week so I don't want to reboot if it won't boot back up. I wouldn't reboot but just delete those logfiles and change the logging settings so it doesn't happen again. Failure to boot can be due to BIOS settings like fast boot you couldn't change remotely.
March 17, 20251 yr Author 3 hours ago, Michael_P said: In maintenance mode, run a file system check on it (click on the drive), and follow the instructions I followed the instructions here (https://docs.unraid.net/legacy/FAQ/check-disk-filesystems/) and got the output below. Should I run a filesystem check on a BTRFS pool? UUID: ae50ab32-ea0b-48e4-9409-dc332166df09 Scrub started: Mon Mar 17 10:47:52 2025 Status: finished Duration: 0:04:41 Total to scrub: 1.39TiB Rate: 5.07GiB/s Error summary: no errors found
March 17, 20251 yr Community Expert The scrub didn't detect any errors, which is good, but previously some data corruption was detected by btrfs: Mar 16 20:20:28 Unraid kernel: BTRFS error (device nvme1n1p1): bdev /dev/nvme2n1p1 errs: wr 0, rd 0, flush 0, corrupt 3, gen 0 Mar 16 20:22:49 Unraid kernel: BTRFS info (device nvme1n1p1): read error corrected: ino 66719 off 31721656320 (dev /dev/nvme2n1p1 sector 1721374696) There could be an intermittent issue, like bad RAM, for now, I would recommend resetting the stats and keep monitoring.
March 17, 20251 yr Community Expert Just now, JorgeB said: like bad RAM Could explain the goofy USB issues too
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.