J1mm1

Thank you, that worked as expected 🙂

That’s nice to read! How do I manually trigger the rebuild though?

Ok, it's strange because I have used exactly the same cables and connectors used for the previous disk that worked just fine for over a year. I have now tried to swap cables with another drive that is still working fine, while disk3 remains unavailable. At power on the disk seems to be mounted correctly, how can I proceed to remove the error state or at least to understand what's happening? Thanks! Oct 12 13:11:24 JimmiNas emhttpd: mounting /mnt/disk3 Oct 12 13:11:24 JimmiNas emhttpd: shcmd (48): mkdir -m 0666 -p /mnt/disk3 Oct 12 13:11:24 JimmiNas emhttpd: /sbin/blkid /dev/md3p1 2>&1 Oct 12 13:11:24 JimmiNas emhttpd: /dev/md3p1: UUID="2b1867d9-164a-4baa-80a6-b3520bf1c68c" BLOCK_SIZE="512" TYPE="xfs" Oct 12 13:11:24 JimmiNas emhttpd: shcmd (49): mount -t xfs -o noatime,nodiscard,nouuid /dev/md3p1 /mnt/disk3 Oct 12 13:11:24 JimmiNas kernel: XFS (md3p1): Mounting V5 Filesystem 2b1867d9-164a-4baa-80a6-b3520bf1c68c Oct 12 13:11:25 JimmiNas kernel: XFS (md3p1): Ending clean mount Oct 12 13:11:25 JimmiNas emhttpd: shcmd (50): xfs_growfs /mnt/disk3 Oct 12 13:11:25 JimmiNas root: meta-data=/dev/md3p1 isize=512 agcount=17, agsize=29303158 blks Oct 12 13:11:25 JimmiNas root: = sectsz=512 attr=2, projid32bit=1 Oct 12 13:11:25 JimmiNas root: = crc=1 finobt=1, sparse=1, rmapbt=0 Oct 12 13:11:25 JimmiNas root: = reflink=1 bigtime=1 inobtcount=1 nrext64=0 Oct 12 13:11:25 JimmiNas root: = exchange=0 metadir=0 Oct 12 13:11:25 JimmiNas root: data = bsize=4096 blocks=488378638, imaxpct=25 Oct 12 13:11:25 JimmiNas root: = sunit=0 swidth=0 blks Oct 12 13:11:25 JimmiNas root: naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=0 Oct 12 13:11:25 JimmiNas root: log =internal log bsize=4096 blocks=57232, version=2 Oct 12 13:11:25 JimmiNas root: = sectsz=512 sunit=0 blks, lazy-count=1 Oct 12 13:11:25 JimmiNas root: realtime =none extsz=4096 blocks=0, rtextents=0 Oct 12 13:11:25 JimmiNas root: = rgcount=0 rgsize=0 extents

Hi all, My NAS was running out of space so I have decided to replace a 500GB drive with a new 2TB one, same size and model of my 2 parity drives. These are the steps I have followed: Force parity check Shut down Remove the 500GB and swap It with the 2TB Power on Select the new drive to replace the missing old One Start Array Everything went fine and Unraid started the data rebuilding process on the new drive but stupidly enough I decided to go in my docker section and stop all the containers. The (poor) reasoning was that I didn't want the container to alter the data while rebuilding. When I got back to the main page, the data rebuilding was interrupted, new disk in error state with emulated content. I don't want to brake anything so I am asking what's the best way to proceed at this point. Diagnostic attached. Thank you! jimminas-diagnostics-20251012-0918.zip

Hello, here to push the same request and add to request adding support for the topic ID within the Unraid telegram agent. I'll explain my need below: I have just one bot managing all the notifications from all my dockers, I've made a group chat with the name of the server and divided it in different topics. All the notification messages from the agents only supporting the "chatid" field end in the "general" topic of the group chat. Some other agents from my dockers already support the "topic ID" field so I can drive their messages into a specific conversation (topic) within the same group just by adding the topic ID in addition to the chat ID. That would be a nice feature to add so that we can direct messages from Unraid into a specific topic within a bigger server group chat. EDIT: I've tried to modify the Telegram agent script by myself but unfortunately it gets overwritten by the system and I can't get the modification to stick. Adding this feature should be as easy as modifying this last part of the Dynamix Telegram.sh script from this: CHATID=$(< $TELEGRAM/chatid); MESSAGE=$(echo -e "$(hostname): $TITLE\n$MESSAGE"); curl -G -s "https://api.telegram.org/bot$BOT_TOKEN/sendMessage" --data-urlencode "chat_id=$CHATID" --data-urlencode "text=$MESSAGE" 2>&1; To this: CHATID=$(< $TELEGRAM/chatid); TOPICID=$(< $TELEGRAM/topicid); MESSAGE=$(echo -e "$(hostname): $TITLE\n$MESSAGE"); curl -G -s "https://api.telegram.org/bot$BOT_TOKEN/sendMessage" --data-urlencode "message_thread_id=$TOPICID" --data-urlencode "chat_id=$CHATID" --data-urlencode "text=$MESSAGE" 2>&1; Where "topicid" is a file similar to "chatid" containig the topic index Does anyone know how could I force these script mods to stick? Thank you

Just for the record. I've been able to fix the issue by doing a security-erase with hdparm. I don't think it actually did anything physically as the process was immediate but the disks size has been restored and I've been able to rebuild the array. No SMART errors on both disks so I don't know exactly what happened but now it's fixed... Thank you

Thank you, I did what you've suggested with no success. I don't understand how the SSD could be damaged though, they are new units with maybe 1 month of power on life and very low stress on Unraid. Hopefully new units I'm going to use as replacement won't fail as fast.

Diagnostics attached. Sorry for not doing it in the first post. Thanks jimminas-diagnostics-20240409-1834.zip

Hi Everyone, I'm posting a new thread as i wasn't able to find something identical to my situation. I have an array composed by 5 discs: 2x 2TB HHD as parity discs 1x 2TB HHD (identical to the parity discs) as main array disc 2x 480GB SSD (disk 2 and 3) Everything was working fine until the update to Unraid 6.12.0, right after the reboot both 480GB ssd have started to be seen with a total size of 1GB each, causing of course a mismatch between the expected size and the detected size. I've tried removing the SSDs from the array and restarting it, they add them back but nothing changed. What options do I have? Should I format the disks and restore from parity? Is there a reason why this might have happened and a way I could prevent it in the future? Thank you all.