Maxrad

I also tried a fresh install (tag "latest") and found that the AutoAdd plugin worked as I'd configured it, but it wasn't listed in the Preferences sidebar, and I couldn't change the AutoAdd configuration. I rolled back to ":2.2.0-1-04", and the AutoAdd plugin was listed in the Preferences sidebar, and I could edit the AutoAdd config in the web interface. I appreciate stike's suggestion to perhaps have a closer look at qbittorrent ("it's more actively maintained and is now the most-used client"). I will do so when I have a bit more time. Thanks.

Plugins – Checking for updates seems to happen super fast in Unraid OS 7.4.0-beta.1 – less than a second, whereas in earlier versions of Unraid it might take 2-5 seconds.

Unraid OS 7.4.0-beta.1 installed on three machines. On all 3, Settings > Fix Common Problems doesn't seem to be ready/working. Everything else seems to be working well. "Report bugs / feedback" link (above) sends me to the release notes.

I successfully: • created a new USB boot (Unraid7.3.0-beta.2) ✅ • downloaded config backup from Unraid Connect (excellent feature/service!) ✅ • copied /config backup to new USB boot (delete key files from /config) ✅ • successfully booted from USB drive (seeing all expected storage devices) ✅ • checked Unraid registration/license. Unraid Pro registration/license appears to be configured okay! And, now referencing TPM (no longer referencing USB Drive GUID). ✅ • Usual plug-ins and services all appear running oaky ✅ (array starts ✅ , docker service and docker containers running fine ✅, Plex Media Server, Tautulli etc... all running okay. ✅ I'm happy to be up and running again. I might defer switching boot to the internal NVME drive pending further testing. Sorry to crash this forum thread with my slightly off-topic panic (quick scan suggested it might be a closely related issue). Bye for now. Thanks.

"waiting up to 30 sec for boot device(s) to come online" "waiting up to 30 sec for boot device(s) to come online" "waiting up to 30 sec for boot device(s) to come online" I'm now getting the "waiting up to 30 sec for device with label UNRAID to come online" where the boot process stops. Booting from 7.3.0-beta.2 installed on internal NVME drive (16 GB partition). The license was looking to the USB Stick GUID (contains the earlier Unraid 6.x.x). I had been running Unraid 7.3.0-beta.2 installed on the internal NVME drive (not dedicated to OS... one other data partition) for several days without issue. The problem occurred shortly after I attempted to move the license registration from the USB stick to the Internal TPM 2.0 module. The attempt failed with the message: Server checks • ENABLE_BOOT_TRANSFER_DISABLED Boot transfer is disabled by the current system state. • BOOT_ELIGIBLE_FALSE The system reported that storage boot is not eligible. Now trying to boot from the NVME partition, NOT successful. Boot process can't get beyond: "waiting up to 30 sec for boot device(s) to come online" "waiting up to 30 sec for boot device(s) to come online" "waiting up to 30 sec for boot device(s) to come online" Frustrating. Troubleshooting steps tried: • Switch USB Ports: Use a USB 2.0 port rather than USB 3.0/3.1. USB 2.0 ports are generally more reliable for the early boot stages of Unraid. • Disable Fast Boot & Secure Boot: Enter your BIOS/UEFI settings and ensure Fast Boot and Secure Boot are disabled. These settings can prevent the kernel from properly handshaking with the USB device. • Check UEFI/Legacy Mode. Still no success. It looks like this will require a bit more troubleshooting time and effort. I will continue to scan the forum for quick/simple solutions.

Small problem with text/layout Settings > Network > Routing Table. Firefox 142.0.1 and Safari 18.6

I had no problem following Plex inc’s security advice – change password and reclaim Plex Media Servers. Two instances of Plex Media Server (docker containers) on Unraid. Reset password, sign-in again, remove authorized devices, reclaim Plex Media Servers, sign-in Plex clients, obtain a new token for Tautulli (docker containers on Unraid). I followed similar process a couple of years ago for an earlier security advice and I practiced this several times (at least once a year) as a routine activity to change passwords.

I have removed Disk Location plug-in and have a much better view of the world (well... the dashboard, at least).

I encountered this kind of problem: file/folder names mangled (when copied over SMB) where a file or folder name ends with one or more blank spaces. I removed any blank space at the end of a file/folder name BEFORE copying to preserve the file/folder name. I hope this helps you troubleshoot your problem.

One Plex account/ID with Plex Pass allows you to grant remote streaming access to 100 friends (friend with a Plex account/ID) – no more than 100.

I just finished a new Unraid build. SilverStone CS382 case. Vector artwork from the SilverStone CS382 Manual, using Pixelmator Pro, to produce PNG image (256x256, 96ppi).

Yep, I had a similar reaction. I was feeling incredulous that an "innocuous" space would result in such a loss! Then I just accepted it, renamed a few dozen directory/folder names and file names, and got on with life. "Life. Don't talk to me about life" Marvin The Paranoid Android On macOS I routinely use A Better Finder Rename 12 at several different points in my "managing media for Plex Media Server" workflow. A Better Finder Rename 12 can scan and correct this type of problem before large copies from macOS Finder to Unraid over SMB.

I encountered this problem and traced it to situations (copy files via SMB) where the file name or folder name ends with one or more blank spaces. It seemed odd that SMB should mangle the file name or folder name when it ends in a blank space. I wasn't inclined to investigate the problem further or raise it with SMB project. Of course, this might not be the trigger for mangled folder/file names in your situation.

Move from 6.12.5 to 6.12.6 completed without incident. Incidentally, enabling Multi-Gen LRU as per notes provided (Unraid OS version 6.12.0-rc3 available) seems to have had no adverse impact.

Ah, yes. Good point. Thanks for the reminder.