dziewuliz

Followed suggestion from another thread ( ). Restarting (and updating) the router fixed the issue. Thanks @JorgeB for suggestions.

By the way, no issues with the running docker containers - they're all responsive.

Deleted all plugins, only left the community one. Same. Example: https://streamable.com/g3lol9 Safe mode is also same.

Lately GUI would take 30secs+ to load each page request, while docker containers ran without issues. Updated to the latest 6.12.10 and the problem persists. Uinstalled most of plugins, and even with the docker stopped, still experiencing slugishness. Sometimes it corresponds with ssh as well - i.e. unresponsive on both. Any recommendations? tower-diagnostics-20240503-1657.zip.crdownload

Thanks, this was indeed the case. Both suggested solutions worked.

Any suggestion, how to automate the refreshing interfaces, so that it would happen on boot/restart?

Same result - became unresponsive over night. Attaching syslog and diagnostics: tower-diagnostics-20231113-1340.zip syslog.zip

Thanks helping with the troubleshooting, @itimpi Stopped docker, and ran the parity check successfully (with some 170 sync-errors) There was an empty system folder on disk1, deleted. Stored syslog there. This was my concern as well - I have a UPS (500w), Corsair PSU (450W) and 10x 3.5HDD's, some 6 of which were connected through power splitter cable. Now, since I was able to complete parity check without issues, would it be safe to assume this is Docker related issue? I will resume Docker, and continue turning on one at a time, to see if it triggers the same issue. Any other suggestions? Thanks a lot.

Recently installed a new i5 cpu, in order to add a second cache disk to have a zfs pool, for redudancy. Since then, I noticed my Unraid server would become unresponsive, during scheduled mover operations, or manual parity check operations - inaccessible via GUI or ssh. The server power is still on and running. Attaching diagnostics and syslog (stops responsing post 6am). tower-diagnostics-20231111-1129.zip syslog.zip

Beer bought. Thanks again both!

Thanks both - after taking the suggested steps, cleaning up my docker mess, my new LSI controller works full speed, and I was able to rebuild parity without issues this time. Lesson learned - stick to the recommended LSI SAS controllers, and avoid the inexpensive SATA expansion boards. @JorgeB let me know your donation link please.

Sorry for the delay in response - had to take a break from fruitless troubleshooting. Adding some additional background on what happened prior to the issue: My previous motherboard had 6 SATA ports (and I have 5 drives), and I switched to a new mb with 4 ports. My first sata expansion board (15$, purhcased on Amazon) shorted upon powering up - I immediately powered off, got myself a PCIe test card, to check there's any damage to the slot itself - looked good. Since then, I used bought another make of SATA expansion board, new SATA cables and connected the drives, and these problems started. Currently, I have parity disabled, and upon rebooting shows crc error count 2. it also happens to be the one connected to the expansion card. What are my options here? 1. Switch to LSI SATA SAS 9211-8i I tried before (albeit at super slow speed). 2. Look for alternative ways to connect the 5th disk

Unfortunately, when I checked in the morning, it had been frozen/non-responsive, so I had to restart the server manually. Anything I can do to identify what has happened? It's like walking on a mine field...

Would like to try that, however my overnight rebuilt now resulted in my parity disk down. tower-diagnostics-20230313-0900.zip

Switched back from LSI HBA back to SATA expansion board, and replaced cables. Now rebuilding at steady 240MB/s.

@trurl I have really neglected my setup, thanks for helping me clear it up. I've rebuilt docker.img, and made system share cache only. tower-diagnostics-20230312-1836.zip

@trurl thanks, reclaimed space by removing dangling docker volumes, after installing Portainer.

tower-diagnostics-20230312-0027.zip

Array was turned on, data rebuilding was paused. I might have had DiskSpeed running (to compare performance for mainboard SATA and LSI HBA speeds) when exporting diagnostics. Thanks for the callout on docker.img size - will look into that. Updating to unRAIDServer-6.11.5...

tower-diagnostics-20230311-2324.zip The speed issue seems to be affected to drives connected to newly installed LSI SATA SAS 9211-8i (SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon]).

There's a chance there were some writing activity while the rebuilding was happening... Went ahead and started array in maintenance mode, and finished data-rebuild, successfully. Now, when I toggled array without Disk2, trying to stop array results in "Array Stopping • Retry unmounting disk share(s)...", and logs: Mar 11 21:57:03 Tower root: umount: /mnt/disk1: target is busy. Mar 11 21:57:03 Tower emhttpd: shcmd (9142): exit status: 32 Mar 11 21:57:03 Tower emhttpd: Retry unmounting disk share(s)... Rebooted, selected the Disk2 again, started array, now it's reconstructing with estimated speed: 3.2 MB/sec, estimated to finish in 60 days 😀 Never had such long estimate before, typically managed to complete parity check within 1-2 days. Should I swap to another drive? Speed issue must be related to newly connected LSI SATA SAS 9211-8i

Recently, after upgrading a motherboard and cpu, same day one of the disks got disabled. I decided to do a full rebuild, and overnight it failed again, with now two disks being emulated. SMART check looks clean, so I assume it could have been the cables? Any recommended steps to take next? tower-diagnostics-20230311-1837.zip

Thanks @itimpi. Can this be marked this as resolved?

Understood. So there's no real difference in using, say, cache-only shares e.g. "appdata", "downloads" and keeping them in unassigned drives, just a different way of managing them?

Hi all, Just built my first unraid system two weeks ago, mainly to be used as a media box, with Plex/Sonarr/Radarr/NZBGet running in the background. I also just bought an nvme 1tb drive, that I initially thought to use as cache drive. But as I looked more at other setups, I learned that most people, with similar needs, don't necessarily use cache, but instead Unassigned Drives. Thus my following question: 1) For my needs, what are the pros/cons on using cache-only shares vs unassigned drive? I don't have plans on running VMS, just occasional docker apps which I also planned to run off the nvme drive (expecting better performance?). 2) If I were to use unassigned drive, and keep appdata/downloads there, would that be considered a bad practice? I was thinking of running backups for appdata separately, in case my nvme died. Thanks in advance!