MowMdown

There's nothing really relevent logged in the logs, however the syslog file you posted shows a container boot-looping which may potentially be the source of this issue. On the docker page you can see the docker uptimes, find out which one is 0 seconds or relatively short uptime and stop it. Ill be honest you might even want to consider running unraid for a while with all dockers stopped and see if the behavior goes away.

Not gonna lie, considering you got help on discord and here and then you run to reddit to complain: https://old.reddit.com/r/unRAID/comments/1uypt4x/quality_of_unraid_updates_is_a_joke/ That's pretty crappy behavior. Especially for something that may or may not be unraid's fault.

Yeah you guys missed the migration requirement from the Immich update announcement.

Those are from using docker folder, they’re snapshots from the docker system. It’s not something the user created.

when you setup a docker container the appdata should be /mnt/user/appdata/CONTAINER_NAME Container name is a placeholder in this example. also 9 times out of 10 you don’t have to alter it so I’m not sure how this became an issue. /mnt/appdata is not correct.

Just to confirm you ran the memtest for a minimum of 24 hours?

You do not have a disk pool named “cache” and your “ServerFiles” is writing to /mnt/cache/appdata which should be /mnt/cache-nvme/appdata However as Itimpi said you should instead use /mnt/user/… instead of disk names and let Unraid manage it.

Switching from USB GUID to TPM is not automatic, it would have had to be done by you on the account.unraid.net page, you would have had to also acknowledged that the USB was to be blacklisted. See: https://docs.unraid.net/unraid-os/troubleshooting/tpm-licensing-faq/

I personally run one every other month except I skip july Jan, March, May, Sept, Nov are the months I run mine

The only thing that looks sus is the split level on the M share, make sure its also set to something, the config shows it as blank

Everything looks good from what I can see, you only have 1 share that mover moves things from your cache pool to the array now, whatever your "M--------e" share is appdata shareUseCache="prefer" # Share exists on cache domains shareUseCache="prefer" # Share exists on cache D-------s shareUseCache="only" # Share exists on cache isos shareUseCache="only" # Share exists on cache M----------e shareUseCache="yes" # Share exists on cache, disk1, disk2, disk3, disk4, disk5, disk6, disk7, disk8, disk9, disk10, disk11, disk12, disk13, disk14, disk15, disk16, disk17, disk18 system shareUseCache="prefer" # Share exists on cache

Im curious as im trying to understand the changes regarding to booting 7.3, what are the specifics of the partition detection and why some older installs dont boot when partitioned "incorrectly"?

I hate to say it, but if you have to ask, you probably shouldn't be doing this. Unraid is not secure as it's only ever meant to be run on a secure LAN and opening unraid to the internet is asking for trouble. If your password is brute-forced there is nothing stopping that person from the rest of your LAN. You're basically giving someone the keys to your home network. Stick with tailscale for remote access. With that said there is a fun and safe way to use a domain with tailscale fully local that lets you use a domain w/o exposing unraid to the internet. https://github.com/MowMdown/unraid-local-dns-guide

Can you post new diagnostics, Im curious if the issue resolved itself.

Click the pool name, click remove pool (not erase) Then create a new pool using the same old name. Assign the disk and start the array

Well the issue I think with that is XFSv4 was updated in the Linux kernel to XFSv5. It’s not like there are two versions of XFS to choose from. That would have probably required LT to engineer a solution when just doing a reformat is easier.

Very unusual but super easy to fix by just reinstalling the container images from previous apps.

Nobody is saying you cant use claude to assist in development. But when you wont respect people's time, they wont respect you.

Herein lies the problem, the community has spoketh, they want humans, who are capable of reading/writing code, doing due diligence. You aren't seeing the forest for the trees.

It's a separate file saved to the share you selected, it will log everything up to the time you reboot so that way the record is not lost after a reboot.

Parity disk is having read/write errors it looks like which explains why you cant correct the emulated disk filesystem Jul 16 15:41:30 TDK kernel: md: disk0 write error, sector=19327536304 Jul 16 15:41:30 TDK kernel: sd 5:0:2:0: [sde] tag#1785 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=DRIVER_OK cmd_age=3s Jul 16 15:41:30 TDK kernel: sd 5:0:2:0: [sde] tag#1785 CDB: opcode=0x88 88 00 00 00 00 04 80 02 e0 f8 00 00 04 00 00 00 Jul 16 15:41:30 TDK kernel: md: disk0 read error, sector=19327541432Might want to check the connection on this disk or try another cable?

I know I and a lot of others would like to see this due having a single format operation can be problematic under certain situations when formatting all disks unraid thinks should be formatted is not desired.

The docker container template probably has /mnt/cache/appdata and you didnt change it to /mnt/user/appdata OR appdata is set to write to cache as primary share and not cache-nvme. You need to check your settings and make sure everything goes to the correct disk/pool/array It also looks like your postgres17 conatiner is also writing to the /mnt/cache/appdata folder as well which could result in a loss of data IF this location doesn't actually physically exist (meaning you dont have a pool named cache).

Connect a monitor to the system and boot into bios to see if the missing disks are even detected. There's no point in doing anything else until you can confirm the BIOS can see or cannot see the disks. The disks could simply just not be getting power from the power cables. No way of knowing. 5 disks don't just up and die from sitting dormant...

I mean, we could also just have an "advanced" option in the docs how to run it manually on the disk mkfs.xfs /dev/mdXp1 and skip all the back and fourth. I just dont know what/if any flags/switches unraid uses along with it.