timepants

I have not had any issues since removing the plugin. Thank you!

I should also mention that when running a Windows install on this machine (not VM) it does not have this issue at all.

Yes, I think it's called the Dynamix S3 Sleep plugin. It was on a list of recommended plugins I installed years ago.

Recently my server has started putting itself to sleep, and I have to manually wake it by pushing the power button. At first I thought it was shutting itself down, but after waking it will show an extended uptime (hours or days, not minutes). Any ides on what could cause it? It has the following specs: Intel Celeron G3930 4 GB RAM 4 SATA drives - 3 HDD, 1 SSD Thermaltake 750W PSU

I had to remove it from the array to make it show up under UD. I unmounted it from UD. I put it back in the array. It is no longer giving the error. Thank you!

I'm assuming UD means Unassigned Devices? The disk does not show up under there. It is only showing under Array Devices with a green light.

It still says Unmountable: No file system. I attached the diagnostics bundle. tower-diagnostics-20200102-1243.zip

Here's the result without -n Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... sb_fdblocks 969459431, counted 976277671 - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done

Running the check produced this result: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... sb_fdblocks 969459431, counted 976277671 - 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 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 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.

I started receiving a message of Unmountable: no file system present on a drive. It was formatted and working previously. It shows the file system as xfs. What should I do to fix this?

I don't see anything on there specifically mentioning a drive showing as unsupported. Would xfs_repair apply in this case?

The error I was getting with the drive was "Unmountable: Unsupported partition layout". Based on what I read online, stopping the array and reformatting it was what I thought would fix it. If this were to happen again, what exactly should I do to prevent data loss?

I have 1 parity drive, and 2 storage drives on my server. 1 of the storage drives stopped being recognized by unraid. I could not get it recognized even after reformatting it in unraid. I tested it on a different machine and had no issues. Eventually after removing and re-adding it to unraid multiple times, it recognized it and triggered a data rebuild. 12 hours later, the array is working fine, but it's missing all the data from the disk. I take it that somehow removing it deleted the contents from the parity disk? Any way to get the data back or is it too late for that?

Thank you for the information on changing the warning threshold. I am using USB drives in my array. Should I shuck these drives instead? Or what is it that makes them not recommended?

I am using a mix of internal and external HDDs in my server. The internal drives consistently stay around 34 C, but my 8 TB external drive (link for reference: https://www.amazon.com/Western-Digital-EASYSTORE-EXTERNAL-WDBCKA0080HBK-NESN/dp/B073LK1F6X) is hitting around 47 C. This triggers notifications on the GUI repeatedly. Is this something I should worry about? Can I disable these notifications?