JorgeB

Your server looks fine. Unraid doesn't create a scripts folder in appdata. That path comes from the guide you're following, so you need to create it yourself. The easiest way is from the terminal (the >_ icon at the top right of the GUI): mkdir -p /mnt/user/appdata/scripts Then copy mover.py into that folder, using the network share if you have appdata exported or any other method you like. About the path mapping question: you run this script on the server itself with the User Scripts plugin, not inside the qBittorrent container. So the container mappings don't matter for where you save the file. I can also see you already have Python installed with the DW Python plugin, which the script needs. For questions about the script settings, like how it connects to qBittorrent, it's best to ask in the support thread for that script or for the binhex container you're using.

Adding the second CPU changed several things at once: PCI bus numbers, NUMA layout, the new numatune block, and the ROM BAR setting during the edits. So I'd look at the earlier and current results separately. Boot 1 is not quite the QXL-only test. The G550 was still assigned, and Windows still loaded its driver and tried to start it (Code 43). It does show that QXL can work on 7.3.2 with the G550 assigned, which is useful. But with failures on about half of boots, one boot can't tell us much either way. The same goes for the ROM BAR setting: one boot with it on and one with it off isn't enough to link it to the result. The BSODs are the most important thing now. Before the CPU change you had Code 43 on QXL, but no crashes. Please post: 1. The crash details for a couple of the BSODs. In Windows, open Event Viewer → Windows Logs → System, find the Event ID 1001 entries (source BugCheck), and copy their text, which includes the stop code parameters. If you can, also zip and attach the C:\Windows\Minidump folder. The dumps name the driver that crashed, which tells us if it is the QXL driver, the Matrox driver, or something else. 2. New diagnostics (Tools → Diagnostics) collected after a boot that crashed, without rebooting the server first, so the VM log has both good and failed starts. 3. Did any BSOD happen before the second CPU was installed and the numatune block was added? If not, save the XML, remove the numatune block for now, and see if the BSODs stop. 4. Have the Debian VM and the server itself been stable since the CPU install? Using Force Stop after a BSOD is fine. Windows has already crashed at that point, so there is nothing left to shut down cleanly. When the crashes are understood, the two comparisons from before are still the ones that answer the original question. Because the problem is intermittent, each one needs several boots, for example five: - With the G550 hostdev removed from the XML (QXL only). - On 7.2.2, with the current XML. One more thing: the AI summary mentions "Update 2026-10-14" and "Recurrence" sections that aren't in your post. Instead of a full write-up, a short line per boot is easier to compare: what changed in the XML, which displays worked, and the Device Manager codes or BSOD stop code.

That makes it simpler. Since the data you care about is backed up or can be ripped again, we can stop the copy and use what is already copied as the new disk3. 1. Optional, but useful: before you stop the copy, open a second terminal and make a list of the files that are not on the new disk yet (replace NAME with your UD mount name): rsync -an --out-format="%n" /mnt/disk3/ /mnt/disks/NAME/ > /boot/disk3-not-copied.txt This only compares file names and sizes, so it should be fast. The list is saved on the flash drive. Use it later to know what to restore from your backups or rip again. 2. In the tmux session, press Ctrl+C to stop the copy. The file it was copying is discarded, and files that could not be read are not kept, so everything on the new disk is complete. 3. On the Main page, unmount the copied 22 TB disk in UD. 4. Stop the array. Go to Tools > New Config, choose to preserve all current assignments, and apply. Then on the Main page: - Set Parity to the first 22 TB disk. - Set disk3 to the copied 22 TB disk (check the serial number). - Leave the old 16 TB parity disk and the old disk3 unassigned. - Do not check "Parity is already valid". 5. Start the array. The copied disk should mount as disk3 with your files, and the parity sync starts. Without the failing disk it should run at normal speed. 6. Go to Settings > Global Share Settings and remove disk3 from the excluded disks. Otherwise nothing new is written to the new disk3. You can turn the mover schedule and downloads back on after the sync finishes. They are safe during the sync, but they make it slower. Keep the old 16 TB parity disk and the old disk3 as they are until the sync completes without errors. After that you can remove the old disk3.

Log is full of spam, reboot and if the docker service still fails to start post new diags.

Tthe new PostgreSQL image works. The "No vector extension found" error is gone. Immich now finds its vector indexes (clip_index and face_index) and starts its database migrations. PostgreSQL is not crashing, what you see is normal: - On the first start with an empty folder, the container creates the database with a temporary server, runs any custom scripts, then stops that temporary server with a "fast shutdown" and starts the real one. "ignoring /docker-entrypoint-initdb.d/*" only means there are no custom scripts, and none are needed. - The later "received fast shutdown request" lines (09:32 and 10:15) mean the container was told to stop, for example by the Stop button, a restart, or a backup plugin. PostgreSQL does not stop by itself like that. At 10:15:09 both containers stopped within a few seconds of each other while Immich was running its migrations, so Immich failed with CONNECTION_CLOSED. The ECONNREFUSED errors are Immich trying to connect while PostgreSQL was stopped. The first Immich start on a new database can take several minutes, because it creates all the tables and imports the geodata. If it is interrupted, it must start again. You can try this: 1. Start PostgreSQL and wait for "database system is ready to accept connections". 2. Start Immich. 3. Leave both alone for at least 10 to 15 minutes. Do not stop, restart or update either container during this time. 4. Then check the Immich log, it should show that the server is listening. If PostgreSQL stops again without you stopping it, check if a plugin is scheduled at that time, for example Appdata Backup, which stops containers while it runs. The database is still empty, so if the migrations keep failing you can safely repeat the reset steps. One more thing: an older start in the Immich log failed with EADDRNOTAVAIL when Immich tried to listen on your server's IP address at port 7979. A container cannot listen on the server's IP directly. If that error comes back, post a screenshot of the Immich container settings (click "Show more settings" and hide any passwords).

Thanks for the update, I missed the custom go file, so yeah, removing that and also booting in safe mode is a good retest.

Don't start the array for now, and you don't need to rebuild anything. Disk4 is very likely fine. The problem is the Marvell controller it's connected to. The diagnostics show the disk link coming up, but the controller can't read the disk because the IOMMU (VT-d) is blocking it. This is a known issue with many Marvell controllers when the IOMMU is enabled. The easiest fix is to connect disk4 to the free onboard Intel SATA port. You currently use 5 of the 6, so there's one free. Unraid identifies the disks by serial number, so changing ports doesn't change the assignments. After rebooting, disk4 should be back in its slot and you can start the array normally. If you need more ports my recommendation would be to get a non Marvell controller, see https://forums.unraid.net/topic/102010-recommended-controllers-for-unraid/ , but if you'd rather keep using the Marvell controller, you can try disabling IOMMU using the kernel options or disabling VT-d in the BIOS. Also, can you check the backup of your old flash drive: open syslinux/syslinux.cfg and post the append line. When you recreated the flash drive, only the config folder was restored, so if you had a custom option there before, like intel_iommu=off, it would have been lost. That would explain why it worked before.

Good news, that output looks good. The missing beginning is just tmux: by default it only keeps the last 2000 lines, and rebuild-tree printed more than that. The important part is the summary at the end, and that is all there. What it says, in short: - It rebuilt the folder structure and found about 18,000 files and 10,000 folders. Those numbers include some small hidden Samba attribute entries, so your actual file count is lower, but most of the disk came back. - About 135 file and folder names could not be reconnected to their data and were removed, mostly .mkv files. A few files lost their information and could not be recovered. - 97 files and 81 folders couldn't be put back where they were, so they were moved to a folder called lost+found. Those usually have number names instead of their real names, but the content is often fine. Next step is to look at what came back. Keep the array stopped and don't format anything. In the normal terminal: 1. Check the disk letter didn't change 2. Mount it read-only. Nothing can be written to the disk this way: mkdir -p /mnt/recover mount -t reiserfs -o ro /dev/sdn1 /mnt/recover 3. Then post the output of: df -h /mnt/recover ls -la /mnt/recover ls /mnt/recover/lost+found | wc -l Also browse it a little, ls /mnt/recover/foldername for example, you can also use Midnight Commander (mc on the console to browse it more easily). If you remember roughly how full the old 10TB disk was, that helps to see how much came back. 4. When done, unmount it: umount /mnt/recover After that we can plan how to get the data safely copied onto XFS disks.

Thanks. That confirms the old docker.img no longer exists anywhere, so it was deleted, not moved or renamed. This also explains why Plex was still working right before you rebooted. Docker runs from a loop-mounted image. If that file is deleted while Docker is running, the loop device keeps it open, so everything keeps working until the image is unmounted at the next reboot or Docker restart. So the file was most likely deleted at some point before the update, maybe even days earlier, and you only saw it on the update reboot. The update itself doesn't delete files on your pools. I can't see what deleted it because the logs from before the update are gone. Unraid itself doesn't do it, and none of your installed plugins delete docker.img. Since the image was at the root of the cache pool, think about whether anything could have removed files there: a cleanup you did from the console or over SMB, a script, or another tool with access to /mnt/cache. Rebooting again is fine. The new image is in place and the second boot used it normally.

Please post the diagnostics

Thanks for the detailed scenarios. You're right that this doesn't look like a RAM problem: it fails the same way every time, and bad RAM wouldn't do that. Looking at your diagnostics again, I think the cause may be the Encrypted Drive Manager plugin. Its auto-unlock is enabled. At every array start the syslog shows: Auto-start is enabled. Proceeding with keyfile generation. Attempting to generate hardware-tied key... Keyfile generated successfully at /root/keyfile Shortly after the array starts, it logs Keyfile at /root/keyfile has been securely cleared. So the key Unraid uses at boot is not your passphrase. It is a key the plugin makes from your hardware. Your NVMe pool was most likely set up with the plugin, so it accepts that key. When you format the HDD later, it gets encrypted with whatever is in /root/keyfile at that moment. That is either your typed passphrase or the file the plugin already cleared, and either way it is not the plugin's hardware key. The drive works until the next reboot. Then the plugin supplies its own key again, and the HDD rejects it. The plugin also explains why the typed passphrase doesn't seem to be used and why the keyfile "comes back." The easiest test is to remove the plugin. First, with the array started, confirm that your NVMe still accepts the passphrase, so you don't lock yourself out of it: cryptsetup open --test-passphrase /dev/nvme0n1p1 Type the passphrase when asked. If it prints nothing, the passphrase is correct. If it prints No key available with this passphrase, it is wrong. In that case, don't remove the plugin; post the result here. If the passphrase is accepted: 1. Remove the Encrypted Drive Manager plugin. 2. Reboot. 3. Start the array, typing your passphrase when asked. If the HDD now mounts, the plugin was the cause. If the NVMe mounts but the HDD still doesn't, the HDD was probably encrypted with the cleared keyfile when you last formatted it, and its current contents can't be unlocked. In that case, format it one more time now that the plugin is gone, and it should keep working after reboots. If it fails again after that, post new diagnostics before you format anything.

If the prompt came back, the rebuild-tree did finish. But it woudl be best to have the full output anyway, not just the end. Before we go further, I need to see the summary (how many files and directories it found, and what went to lost+found) and any error lines further up. You don't need to run anything again. tmux keeps everything it printed, and you can save it to a file: 1. In the same tmux window where rebuild-tree ran, type: tmux capture-pane -p -S - > /boot/rebuild-tree.txt This saves the whole scrollback of that window to the flash drive. 2. Open the normal terminal (the >_ icon you used before) and type: cat /boot/rebuild-tree.txt Copying from that window works the usual way, so you can paste the output here. If it's long, you can attach the file instead. It's on the flash drive as rebuild-tree.txt. Same as before: keep the array stopped, don't mount the disk, and don't format anything. Once I see the output, the next step is to mount the disk read-only and look at what came back. Read-only means nothing changes on the disk.

Thanks for the details, and sorry for the repetition. That clears up the cache question. Since enabling caching on the disks themselves made no difference, we can set that aside. The change after enabling caching in the PERC settings is interesting, because it points at the controller rather than the disks. Which setting did you change, exactly (for example "Disk Cache Policy" for non-RAID disks)? After the reboot, what does smartctl -g wcache /dev/sdX show for one of the SAS disks? The controller can manage the cache setting of the drives behind it, so a change made with smartctl may not stay in effect. Drive write cache is the normal state for most disks, and your SATA array disks already have it enabled. XFS sends cache flushes to protect its metadata, so a power loss risks only data that was still being written at that moment. 65–80 MB/s is still slow for these disks, so the next useful step is to take the copy out of the test. Run the read speed test above for one SATA disk and one SAS disk. This only reads. Then run this write test to a file on one disk with free space: dd if=/dev/zero of=/mnt/diskX/ddtest.bin bs=1M count=20000 oflag=direct status=progress rm /mnt/diskX/ddtest.bin These disks should give well over 150 MB/s on both tests. If they don't, the copy process isn't the cause, and the controller path is the main suspect. In that case I still recommend trying a true IT-mode HBA such as the Dell HBA330 Mini.

On the first boot into 7.3.3, the cache pool mounted normally with both devices and all of its existing data. Then Docker started. It is set to use /mnt/cache/docker.img, and the log shows it found no file at that path, so it created a new, empty 20 GB image. That is why the Docker page was empty. Unraid only creates a new image when the configured file is missing. It never replaces an existing one, and the update itself does not delete or move files on your pools. So the old image was already missing from /mnt/cache before that boot, or it was somewhere else. Unfortunately the diagnostics only have the logs from after the update, so I can't see what happened before the reboot. To help find out, please open a terminal and post the output of: ls -la /mnt/cache find /mnt -maxdepth 4 -name "*.img" -exec ls -la {} \; If an older docker.img shows up anywhere, please don't delete it yet. For the containers you didn't install from Apps: "Previous Apps" can't reinstall those. Their settings are still saved on the flash drive, though. Go to Docker > Add Container, open the Template dropdown and select each one under User templates. The fields fill in from your old settings. Check them, then click Apply. Their appdata is still there, so they should pick up where they left off. Will it happen again? Only if the image file goes missing again. Nothing in the logs points to 7.3.3 causing this, and the second reboot used the new image normally. If it does happen again, please grab diagnostics before you reboot or reinstall anything. That way we have the logs from before it happened.

The PostgreSQL log shows two things: - The database is brand new and empty. Immich can't find even its first table (system_metadata), so nothing from the old install is in it. - The PostgreSQL image you are using (PostgreSQL 16.8) doesn't include the vector extensions that Immich needs (vchord/vector). Recent Immich releases need a PostgreSQL image with VectorChord. A plain postgres image or the older pgvecto-rs image won't work anymore. Because the database is empty, the easiest fix is to start it fresh with the correct image: 1. Stop the Immich and PostgreSQL containers. 2. Delete the PostgreSQL container's appdata folder (the database folder only, not your photos/upload folder). It contains no Immich data now. 3. Edit the PostgreSQL container and change Repository to: ghcr.io/immich-app/postgres:16-vectorchord0.4.3-pgvectors0.2.0 Keep the same user, password, and database name settings that Immich uses. 4. Start PostgreSQL first. Wait until its log shows "database system is ready to accept connections", then start Immich. If it still fails, post the full Repository value of both containers and the new logs from both. Your earlier attempt to upload to Immich may have left files in the Immich upload folder. Your originals are still on your phone, so the cleanest start is an empty upload folder.