MichaelD

ok, then I guess I have to wait until it happens again and re-post my diagnostics file then, right? I guess nothing showed up as I did a reboot after the last incident for the Unraid update... And fyi, in Immich you have the option to use ML on Unraid directly or from a remote computer. I have chosen the remote option, so Immich workload was small. And I do not want to teach you at all, just to clarify :-) Thanks for your support, I come back when it happens next time.

yes, sorry for not mentioning, I get the error message from "fix common problems". The heavy Machine learning I do via my MacMini, so Immich is handing over 1 pic after another. This works well. But now no more heavy lifting on immich but still these "Unraid timeouts"...

Hi, I have a Dell Wyse running latest Unraid 7.2.3. The error "running out of memory" also occured on 7.2.2. After running smoothly some hours the unraid computer is not reachable anymore (neither by Unraid Connect). After some hourse (4-5h) the computer wakes up again and becomes responsive again. I sometime recognized high CPU load. This occured first time after I installed Immich. Then I reduced in the Immich docker the resources availabe to immich to keep unraid alive, even it Immich needs a lot of resources. Now all my pictures are in Immich and there should be no additional workload on immich as all pics are worked on with machine learning / face recognition, now new pics are added (or only 2 a day). Immich has no access to CPU 0 (from the 4 existing ones) this should help to keep unraid alive. But I thought as this is running in docker it should not lead to a "running out of memory"? Maybe this is not even connected to Immich. Attached my diagnostics file, hope this gives some hints to one of wizards here :-) Thanks for your support and happy xmas! Best, Michael tower-1-diagnostics-20251223-2133.zip

Hi, thanks for this nice software! I installed it and it work great, only side effect is that my disk do not stop spinning after 15min when I run this Docker. If I stop this Docker, the disk go to sleeping mode the way I set it up after 15min. Any chance to avoid this effect? Best, Michael

This Alternative B worked well, it rebuild first my second parity. Then I followed with Alternative A which rebuild my Disk 1. Thanks @JorgeB for your support!!!!

Hi, I tried to install an UPS and during this process I killed my unraid by removing power during running Unraid 🫣 I was running 7.1.3 I worked with Disk 1 and had 2 parities. Now after reboot I see: Parity disabled Parity 2 active Disk 1 disabled All harddrives use XFS. I stopped the array, restarted with Maintenance box checked and ran "Check Filesystem Status Disk 1 with these results for xfs_repair status <code> Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 3 - agno = 1 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. <\code> No file system corruption detected. Is this now the right procedure?: Alternative A) 1. Stop the array. 2. Go to Main → Array Devices. 3. Unassign Disk 1 (set it to “No Device”). 4. Start the array. (yes, without Disk 1 temporarily) 5. Stop the array again. 6. Reassign the same disk to Disk 1. 7. Start the array. • Unraid will now offer an option like: Disk 1 appears to be disabled but contents are emulated — do you want to rebuild the disk onto itself? 8. Click “Yes” to start rebuild. This will rebuild Disk 1 onto itself, which is safe and keeps your data. OR would it be saver to do it this way?: Alternative B) 1. Stop the array. 2. Go to Main -> Array Devices 3. Unassign Disk 1 AND the disabled Parity 4. Start the array 5. Stop the array again. 6. Reassign the "old" Parity to Parity but do not yet reassign Disk 1. 7. Start the array. • Unraid will now offer an option like: Parity appears to be disabled but contents are emulated — do you want to rebuild the disk onto itself? 8. Click “Yes” to start rebuild. 9. If successful repeat the same procedure now as described in Alternative A. Question: What should I do next?!? Thanks for your help, best, Michael tower-1-diagnostics-20250618-0009.zip

you are the best! Thanks a lot, this worked, full 1GB is available again! Thanks for your friendly and fast support! Team Interlagos rulez!!!! Best, Michael

root@Tower:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS loop0 7:0 0 556M 1 loop /usr loop1 7:1 0 69.1M 1 loop /lib sda 8:0 0 931.5G 0 disk └─sda1 8:1 0 931.5G 0 part /mnt/cache sdb 8:16 0 16.4T 0 disk └─sdb1 8:17 0 16.4T 0 part sdc 8:32 0 16.4T 0 disk └─sdc1 8:33 0 16.4T 0 part sdd 8:48 0 16.4T 0 disk └─sdd1 8:49 0 16.4T 0 part sde 8:64 1 29.9G 0 disk └─sde1 8:65 1 29.9G 0 part /boot sdf 8:80 0 119.2G 0 disk md1p1 9:1 0 16.4T 0 md /mnt/disk1 lsblk after docker is disabled

root@Tower:~# fdisk -l /dev/sda Disk /dev/sda: 931.48 GiB, 1000171323904 bytes, 1953459617 sectors Disk model: Extreme Pro 55AF Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 2097152 bytes Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type /dev/sda1 64 1953459616 1953459553 931.5G 83 Linux

Hi, here the results of "lsblk": root@Tower:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS loop0 7:0 0 556M 1 loop /usr loop1 7:1 0 69.1M 1 loop /lib sda 8:0 0 931.5G 0 disk └─sda1 8:1 0 931.5G 0 part /var/lib/docker /mnt/cache sdb 8:16 0 16.4T 0 disk └─sdb1 8:17 0 16.4T 0 part sdc 8:32 0 16.4T 0 disk └─sdc1 8:33 0 16.4T 0 part sdd 8:48 0 16.4T 0 disk └─sdd1 8:49 0 16.4T 0 part sde 8:64 1 29.9G 0 disk └─sde1 8:65 1 29.9G 0 part /boot sdf 8:80 0 119.2G 0 disk md1p1 9:1 0 16.4T 0 md /mnt/disk1 are the docker containers "stealing" disk space? If yes, where could I define the docker sizes and change it?

Hi, I am using a 1 TB SanDisk Extreme Pro SSD as Cache (sda, xfs Filesystem). But it only shows 256GB Size, (of which 119 GB are used and 137GB free). Any idea where to look for the missing 744 GB? I searched the forum without success, any recommendations? Thanks a lot! latest Unraid 7, if I should post other log files, please let me know. Best, Michael http://192.168.178.3/logterminal/sda/: text error warn system array login Feb 14 09:44:14 Tower kernel: sd 0:0:0:0: [sda] 1953459617 512-byte logical blocks: (1.00 TB/931 GiB) Feb 14 09:44:14 Tower kernel: sd 0:0:0:0: [sda] Write Protect is off Feb 14 09:44:14 Tower kernel: sd 0:0:0:0: [sda] Mode Sense: 37 00 10 00 Feb 14 09:44:14 Tower kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA Feb 14 09:44:14 Tower kernel: sd 0:0:0:0: [sda] Preferred minimum I/O size 512 bytes Feb 14 09:44:14 Tower kernel: sd 0:0:0:0: [sda] Optimal transfer size 2097152 bytes Feb 14 09:44:14 Tower kernel: sda: sda1 Feb 14 09:44:14 Tower kernel: sd 0:0:0:0: [sda] Attached SCSI disk Feb 14 09:45:27 Tower emhttpd: online: SanDisk_Extreme_Pro_55AF_323230373732343033313634-0:0 (sda) 512 1953459617 Feb 14 09:45:27 Tower emhttpd: import 30 pool device: (sda) SanDisk_Extreme_Pro_55AF_323230373732343033313634-0:0 Feb 14 09:45:28 Tower emhttpd: read SMART /dev/sda Feb 14 09:45:44 Tower emhttpd: import 30 pool device: (sda) SanDisk_Extreme_Pro_55AF_323230373732343033313634-0:0 Feb 14 09:45:45 Tower emhttpd: /sbin/blkid /dev/sda1 2>&1 Feb 14 09:45:45 Tower emhttpd: /dev/sda1: UUID="92c09353-170e-4deb-905a-427138038db9" BLOCK_SIZE="512" TYPE="xfs" Feb 14 09:45:45 Tower emhttpd: shcmd (41): mount -t xfs -o noatime,nouuid /dev/sda1 /mnt/cache Feb 14 09:45:45 Tower kernel: XFS (sda1): Mounting V5 Filesystem 92c09353-170e-4deb-905a-427139038db9 Feb 14 09:45:45 Tower kernel: XFS (sda1): Ending clean mount Feb 14 12:44:34 Tower nginx: 2025/02/14 12:44:34 [crit] 10774#10774: *68647 connect() to unix:/var/tmp/sda.sock failed (2: No such file or directory) while connecting to upstream, client: 192.168.178.56, server: , request: "GET /logterminal/sda/ HTTP/1.1", upstream: "http://unix:/var/tmp/sda.sock:/", host: "192.168.178.5", referrer: "http://192.168.178.5/Main" ** Press ANY KEY to close this window **