apandey

Before you go too far, try resetting only the network and see if you can re-do the setup the way you would like. delete network.cfg and network-rules.cfg under config folder on your flash drive and reboot It doesn't look like you really want to start fresh, but rather just start fresh on certain things while keeping most of your setup. Someone can better advise on what to do if you post diagnostics

what is previously here? Did you do any updates between this previous and current state? Are you sure about this? The diagnostics you posted has a bunch of dockers running, in fact python is taking 1 core too. I see sabznet running, and probably a few other things. docker appdata is under /mnt/user, maybe some other container mounts too? docker and VM services are enabled from your diagnostics. Are clients connected over network too - smb, nfs, ssh? If things have changed since that diagnostics, post a new one when you have activity stopped Also, as mentioned earlier, fix common problems is showing issues, including incompatible plugins. How have you arrived there? was there an unraid version upgrade involved at some point? better to resolve issues and be up-to-date first in that case

Just to be clear, that's 100% of one core. Your overall cpu usage doesn't look high shfs is the merge filesystem used by shares that gives the shares a unified view across all the array and pool drives. If there are lots of writes, it will have overheads. Essentially this is the /mnt/user mount Moving any drive specific writes to /mnt/disk is one way to avoid shfs overhead, though it would bypass the shares so not always desirable You also have some mount related warnings on fix common problems. You should fix those docker containers too

What permissions and ownership do you see in terminal? In a correct setup, you would see owner as nobody:users and drwxrwxrwx. You may have to check PID/GID/UMASK on transmission container if that's not the case

Then your bios is likely just UTC, which is generally a good recommendation to set hardware clocks anyway. Is this causing any specific issue? See this too https://superuser.com/questions/282551/should-i-set-my-bios-to-local-time-or-utc

What exactly was the error that you see / acknowledged? If it's a crc error, it might be due to connections / cables

Does your new setup has a pool?

Yes, looks like a cpu problem. Since you see all cores when booting windows, try running a cpu benchmark and look for any errors One idea can be to disable any hyper threading, run prime95 single thread test, then go to task manager and set cpu core Affinity to only 1 core you are testing. See for stats like killed threads There might be other tools lik occt that can help to verify as well. You just want to test core stability

Are you sure system clock has a timezone showing as EST. It might just be UTC and gets converted to timezone when unraid boots up

Looks like a disk issue, lots of errors in syslog trying to communicate with that 16TB drive

Shutdown the server and check all cables are properly seated. If you can, try replacing the data and power cable for that particular drives If you still end up with same end result, post diagnostics

If you are connecting to the unraid share (using 192.168.0.178 or unraid host name resolving to that IP), it will be using that 1G network. Why aren't you mapping the truenas IP directly on windows?

What is the share mapped by? Name or IP. If name, it really depends on what IP that name resolves to on your client. If IP, you can directly address whatever actual interface as long as there is a route to it

/dev/sdX is the disk. /dev/sdX1 is a partition on that disk What filesystem do the disks have? What type of system did they come from? Do you have unassigned devices plug-ins installed on unraid? You need those to mount disks that are not part of unraid array/pools

nobody:users is the expected owner for shares, drwxrwxrwx for dirs and -rw-rw-rw- for files When you use docker containers mounting any shares, you should run them with same PID / GID as nobody / users to maintain permissions

Post diagnostics next time after a drive is disabled but before reboot

You have pcie errors spamming the logs. Try adding pcie_aspm=off to boot args in syslinux config See this thread for details

Try putting hba on E1, gpu on E5, no other pcie and see what bios says

How are you planning to attach the drives to NUK? USB is not recommended as it may not pass SMART and might not expose disk IDs properly You can always boot the NUK with unraid USB to test what works and what doesn't

PCIe 2.0 x4 is 2GB/s. Even with all 16 disks concurrently active, it should give them 100MB/s each. However, if the disks are in unraid array, except for parity rebuild, all disks are almost never concurrently in use, so you will get a lot more most of the time. Your parity rebuilds will be slower (but still respectable) if all disks are part of same array

Just remember that unraid doesn't stripe the files across disks, so a file only exists on one single disk. Any multi disk read/write will only gain a speedup if there are multiple concurrent clients to separate files

Should this advice to change subject be amended now that threads could be marked solved. I see we get a mix of both approaches today. Consolidating on mark solved is probably good now

yes

try this instead #!/bin/bash for disk in $(lsblk -I8,65,66 -ndo name); do smartctl --test=short /dev/${disk} done it lists names of all devices using lsblk, where major device numbers as 8, 65 or 66 (sd*), then loops through them

Follow the link