Sinister Crayon

So I'm not sure if this is a problem that others are hitting, but I have noticed that since 7.3.0 this plugin seems to have stopped working. In fairness I only have a single SAS drive in my array but even clicking the spin down icon will just spin the icon for a minute and the drive never spins down. The logs do say "SAS Assist v2024.11.25: Spinning down device /dev/sda" but it never seems to actually spin down. Might be a bug, might be my specific setup I'm not sure. The plugin did seem to work with 7.2.x though. EDIT TO ADD: I did a bit of troubleshooting when I had a moment. It appears that all the "normal" SAS spindown commands like sdparm just don't work on that disk. Not sure what has changed... might be something at the kernel level. Probably not something you can fix unfortunately and it might be my controller... maybe a driver issue? Who knows?

Very well. Submitted a ticket and referenced this thread.

Yes. In this case it was "18171". It was one of my NFSD processes, again. I was able to stop the array and restart it and the problem is resolved again. I did not reboot the server, just restarted the array. I did try to just restart NFS first but it wouldn't stop the NFS services, just hung until I stopped the entire array. The SYSTEM memory taken up by the rogue NFSD process is still taken up; it got up to 24G of RAM and my machine's still showing a "SYSTEM" memory load of 24G while under normal operations it usually sits around 6-8GB of SYSTEM memory. Of note; I have some machines connected to the array via NFS. One of them at the time the problem occurred showed an error that the NFS server was not responding in its DMESG logs. However, everything appeared to be working just fine as in I could enter and browse the NFS mounted filesystems without an issue and all the apps running on it were running fine. I did reboot this box as part of my troubleshooting and during boot it refused to reconnect to the NFS server (the unRAID machine). It was only after I restarted the array that the NFS mounts came back without an issue. The mount line used to mount those NFS mounts is; "10.10.10.202:/mnt/ixios/sandata /sandata nfs _netdev,noatime,nodiratime,fsc,nconnect=8,actimeo=1,timeo=600 0 0" I may reboot this system today to try to free that memory up unless you have any specific commands you'd like me to run to gather data. I have attached an updated diagnostic dump since I did not reboot the server, just restarted the array. The problem is not occurring right now since I restarted the array except for the "lost" memory. If it starts again I can try to run the strace again but I just tried strace again on an existing NFSD process but it doesn't appear I can attach to any of them. strace against another process running on the system (Pi-Hole) returns data as expected. NFSD processes all return "Operation not permitted" ixios-diagnostics-20251208-0720.zip

Alright... problem has occurred again. I tried doing "strace -p PID" but got "Operation not permitted."

Will do. I'll start on a reboot now and will post an update when it happens again. For the record I had already increased the NFS threads to 32

Got an unRAID box recently moved to production. I have a problem after a couple of days that's driving me nuts and is consistent. At some random point a single NFSD daemon suddenly spikes to 100% CPU and hangs there. Once this happens, the SYSTEM memory in the dashboard starts rising and rising eventually exhausting all the memory in the system. There aren't a ton of NFS clients but this is the main use case for this server. Storage backend is a ZFS pool. This is not new per se; the array itself was only recently built but has been problematic since the start. Basically runs for a few days then stops responding with a crashed NFSD (or once, more than one) process eating up a CPU core of utilization and memory growing out of control. NFS services are generally unaffected except for this constant memory growth. All the clients are operating completely normally and none of them seem particularly busy either. Checked DMESG and SYSLOG for errors but nothing seems amiss. Since this a Dell T440 server I checked iDRAC to see if it had snagged any hardware failures but nothing comes up there either. Diagnostics attached. Server's still running and I'm monitoring the situation but the memory use is still growing. Not sure what'll happen when the process eventually eats all the RAM. ixios-diagnostics-20251127-1133.zip

That was it. For anyone else searching this in future, create a single pool of ALL your devices not just the main pool data devices and assign them all. It'll get sorted out on first startup. Thanks, @JorgeB

Thank you. No that wasn't clear but indeed this seems to have resolved the problem. Going to try a couple of reboots to be sure before I mark it as a solution but it's looking good at the moment.

Context here; your response to my earlier concern was "Yes, you can, and you must. Subpools devices are assigned together with the other devices; all together, they will be sorted at array start"

You literally told me I "must" use "Auto" filesystem. If I select Auto filesystem then I can't assign subpool devices.

A scrub is probably going to take 24 hours or more and I think is unlikely to resolve the issue. The fact that it imports means that it's usable... I can literally read data from it. I tried booting up an Ubuntu live USB stick and I can import the pool there too. No issues. Are you telling me there's no effective way to just import an existing ZFS pool into unRAID? Imagine for a moment this is an existing ZFS pool (for example from TrueNAS) that I want to import into a new unRAID install; how would I do that? Is there any configuration on the USB stick I should be looking at? Some saved value that has gotten broken somewhere?

root@Ixios:~# zpool import ixios root@Ixios:~# zpool status -v pool: ixios state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-8A scan: scrub canceled on Mon Nov 17 13:47:12 2025 config: NAME STATE READ WRITE CKSUM ixios ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 sdm1 ONLINE 0 0 0 sdn1 ONLINE 0 0 0 sdc1 ONLINE 0 0 0 sdj1 ONLINE 0 0 0 sdf1 ONLINE 0 0 0 sdk1 ONLINE 0 0 0 sdg1 ONLINE 0 0 0 sdh1 ONLINE 0 0 0 sde1 ONLINE 0 0 0 sdl1 ONLINE 0 0 0 sdd1 ONLINE 0 0 0 sdi1 ONLINE 0 0 0 special mirror-1 ONLINE 0 0 0 nvme1n1p1 ONLINE 0 0 0 nvme3n1p1 ONLINE 0 0 0 logs mirror-15 ONLINE 0 0 0 nvme0n1p1 ONLINE 0 0 0 nvme2n1p1 ONLINE 0 0 0 errors: Permanent errors have been detected in the following files: /mnt/ixios/appdata/syncthing/index-v2/folder.0002-bchrqmal.db

BTW, I'm aware of the errors. That was a DB file that got corrupted due to the sudden power off. Non-critical file and replaceable.

root@Ixios:~# zpool import -f -m -N -d /dev/sdm1 1247441232252185846 ixios cannot import 'ixios' as 'ixios': I/O error Destroy and re-create the pool from a backup source. root@Ixios:~# zpool import -f -m -N -d /dev/sdn1 1247441232252185846 ixios cannot import 'ixios' as 'ixios': I/O error Destroy and re-create the pool from a backup source. root@Ixios:~#

Done. Pool inaccessible. Did not import. ixios-diagnostics-20251118-1243.zip

I can't leave the filesystem set to "Auto". It doesn't give me the ability to add subpools unless I set it to ZFS and without the metadata the pool is dead anyway. I did isolate a shutdown script that was importing the pool and have removed that... so that mystery's solved at least.

And again, after stopping the array the pool is apparently mounted. Ran another diagnostic with array stopped. ixios-diagnostics-20251118-1205.zip

Done. Note that after just starting the array the pool is unusable and not imported. ixios-diagnostics-20251118-1204.zip

Done ixios-diagnostics-20251118-1156.zip

UPDATE: Not fixed, but functional. Sort of. Did a bit of faffing around. After starting the array and stopping it a couple of times it finally exported properly on array stop. So I then went in and started the array one more time and it seems to be up and running. All the Dockers are running and the shares appear to be working. However, the GUI of UNRAID still thinks the array is not running so I can't manage shares or anything. Going to "Shares" tab gives me "There are no mounted array or pool disks - cannot add shares." Assistance still required to get myself out of this pickle... but at least my array is functioning again even if not working well.

OK I've got a problem here that I'm having some trouble resolving. Had a hard shutdown of my system and after reboot my ZFS array (12 disk RAIDZ2 single VDEV with mirrored set of Special devices and a mirrored set of log devices) is not usable any more. The pool and special subpools were showing as one device in the pool but no devices listed. I tried to recreate the array as best I could by changing the numbers and putting all the devices back in, but it would not start saying that the subpools were 'orphans'. Did a "New Config" as I was running out of ideas and was able to put the array back together and start the array, but on starting the array it comes up as "Unmountable" and only allows me to format. Here's the other weird part; when I go to stop the array all of a sudden it mounts the array and boom all the data is there but obviously all the services are shut down. After a clean reboot, I can import the pool with a "zpool import" but again everything seems broken and I can't start the services or the array properly. Diags attached. For the record this has all been with 7.2. This was a fresh build with 7.2 with a whole new pool and I was busy restoring data back. I had made some of it live so I'd really rather not lose data since the last backup (last night) and I really don't want to start the restoration seeds all over again (~30TB already restored before this happened) ixios-diagnostics-20251118-1123.zip

In fairness, if you go through the community apps and install, 4gb is the default max on that. I just did the install and upped it to 8Gb based on this thread, but the app install needs to be refreshed.

Literally just trying this for the first time. Followed the instructions to a 't' and I keep getting the following error; "sed: -e expression #1, char 313: unknown option to `s'" Any thoughts? My command line comes out as; docker run -d --name='storagenode-v3' --net='bridge' --pids-limit 2048 -e TZ="America/Chicago" -e HOST_OS="Unraid" -e HOST_HOSTNAME="Precision" -e HOST_CONTAINERNAME="storagenode-v3" -e 'WALLET'='<redacted>' -e 'EMAIL'='<redacted>' -e 'ADDRESS'='<redacted>:28969' -e 'STORAGE'='16TB' -e 'BANDWIDTH'='' -l net.unraid.docker.managed=dockerman -l net.unraid.docker.webui='http://[IP]:[PORT:14002]/' -l net.unraid.docker.icon='https://raw.githubusercontent.com/dalekseevs/Unraid-Docker-Templates/master/logos/storj-logo-png-transparent.png' -p '28967:28967/udp' -p '28967:28967/tcp' -p '14002:14002/tcp' --mount type=bind,source="/mnt/user/storj/storj/identity/storagenode/",destination=/app/identity --mount type=bind,source="/mnt/user/storj/storage/",destination=/app/config 'storjlabs/storagenode' All the locations exist and are set up correctly. I have my identity files. config.yaml is created as are folders but ends with the same error.

Thanks so much. Yeah, I actually ended up deleting and re-deploying it, but also rebooted my NAS out of curiosity (and it wasn't sleeping disks properly so that was another issue entirely)... looks like it's all working perfectly now with no privileged mode required. Awesome :)

This is such a cool container!!! Thank you. I just started using it for monitoring but hitting a bit of a snag. Basically I can monitor just fine but can't apply new profiles to my fans. The error in the console is "coolercontrold::api] Internal Error: Error on it8613:fan2 for Manual Control - Unable to set pwm_enable for "/sys/class/hwmon/hwmon7/pwm2_enable" to 1. Most likely because of a limitation set by the driver or a BIOS setting; Error: Read-only file system (os error 30)". Now, I tried resetting it to read-write in the container config but it doesn't seem to make any difference. I am out of time to troubleshoot it this morning as I have to get to work... but just to confirm my suspicion; given this error will I have to run this container privileged in order to control my fan profiles? I suspect so; I tried echoing "1" to /sys/class/hwmon/hwmon7/pwm2_enable and it worked fine, but the container clearly can't for whatever reason.