-
Slow Parity Check after upgrading to 7.3.1
SOLVED - though I cannot explain how. After seeing that it was related to a pegged CPU, I shut down my Unraid VM and tweaked it's settings: Reduced Cores from 12 to 6 (12 was always just a flex anyway but with 48 threads available, why not) Changed the vIOMMU setting to VirtIO from "Intel (AMD compatible)". I am not running any VMs in Unraid, so I don't think this would even apply anyway. Increased RAM from 64000 to 65536 (another flex, I should probably reduce it). Added a TPM State devices - just in case I can use it to get off the thumbdrive. None of these changes should have had any impact, but clearly they did. Or it was just the reboot? And with a sync running its only using 30% of one core:
-
Slow Parity Check after upgrading to 7.3.1
Looks like I am somehow being CPU limited. When running a sync, the mdunraidd0 process is consuming 100% of one core. This wasn't a problem before the unraid upgrade. I am using an AMD EPYC 7402P 24-Core, the individual cores aren't super fast, but they don't need to be for this. Should certainly not be pegged by a simple parity calculation. This tells me that something is not right. It could be something on the Proxmox side, since I did apply updates there at the same time. Though nothing that should have made this large of a difference. I'll keep digging, but would appreciate any input if anyone has seen this, particularly on AMD CPUS.
-
Slow Parity Check after upgrading to 7.3.1
Slightly faster in maintenance mode, 50MB/s vs 45MB/s, still no where near where it should be.
-
Slow Parity Check after upgrading to 7.3.1
The 3TB drives are slower, I show that in my speed test results... but not 44 Mbps slow. As I said, I just did a parity scan 2 days ago, and it was running at about 135 Mbps from the start (probably sped up after 3TB, but not by much because it finished within an hour of its initial estimate). As far as I can tell, the only thing that changed was the upgrade of Unraid. I did upgrade the Proxmox host as well, but I am passing the drive controller through to Proxmox, so the host OS shouldn't have much impact. Copying files between drives, and performing "hdparm -t --direct /dev/sdX" shows all of the drives with the expected read performance.
-
Slow Parity Check after upgrading to 7.3.1
The 3TB drives are from my previous array... there are 5 more 3TB drives in the system that are unassigned. They have never been an issue until this upgrade, and I'd prefer to keep them. I agree that its a bit overkill, but I have been bit before in a Raid 5 array and chose Unraid over a raid 6 array because I could mix drive sizes, allow drives to spin down, and still have comparable redundancy. Drives are cheap
-
Slow Parity Check after upgrading to 7.3.1
None, the drives were spun down when I started the parity scan. Right at the beginning. As you can see in my first reply, the drives test at ~150MB/s I also verified this by copying files between drives (though I didn't share that). Its only the sync that seems to be slow.
-
-
Slow Parity Check after upgrading to 7.3.1
Here are the 7 drives that make up my array, they are all plenty fast enough. /dev/sdf: Timing O_DIRECT disk reads: 622 MB in 3.00 seconds = 207.00 MB/sec /dev/sdg: Timing O_DIRECT disk reads: 534 MB in 3.02 seconds = 177.02 MB/sec /dev/sdh: Timing O_DIRECT disk reads: 648 MB in 3.00 seconds = 215.65 MB/sec /dev/sdi: Timing O_DIRECT disk reads: 566 MB in 3.01 seconds = 188.15 MB/sec /dev/sdj: Timing O_DIRECT disk reads: 474 MB in 3.01 seconds = 157.45 MB/sec /dev/sdk: Timing O_DIRECT disk reads: 438 MB in 3.00 seconds = 145.98 MB/sec /dev/sdl: Timing O_DIRECT disk reads: 450 MB in 3.01 seconds = 149.71 MB/sec Yet:
-
Slow Parity Check after upgrading to 7.3.1
I upgraded yesterday from 7.2.x (want to say 7.2.4 but not sure). Prior to doing the upgrade I ran a parity-check (it had been a couple of months), right from the start it told me it would be just over a day to complete, and it was accurate within a couple of hours. Post upgrade, I decided to kick off another parity check to generate some heat (I am working on tweaking my fan curves on the host system, I run Unraid in a VM with pass through disk controller). This post upgrade parity check is estimating over 3 days. It shows it reading my disks at 44MB/s, compared to my typical ~135MB/s. Anyone seeing similar behaviour?
-
Stop array without spinning up drives
I suppose that makes sense, that way Unraid can determine if the array was stopped cleanly on the next start of the array. Thanks for clarifying.
-
Stop array without spinning up drives
For some reason, stopping the array requires the drives to spin up. Its a minor thing, but is an annoyance when I am stopping the array just to shut down the server for maintenance. Does stopping the array actually require Unraid to access all drives?
-
Recurring NT_STATUS_NO_SUCH_USER messages in the log
Was the source of this ever identified. I have the exact same behavior. exactly 1 second after every minute I get: Jul 11 13:21:01 bigbird winbindd[2537634]: [2025/07/11 13:21:01.719001, 1, traceid=1968] ../../source3/winbindd/wb_queryuser.c:409(wb_queryuser_got_gid) Jul 11 13:21:01 bigbird winbindd[2537634]: Returning NT_STATUS_NO_SUCH_USER Jul 11 13:21:01 bigbird winbindd[2537634]: xid.type must be ID_TYPE_UID or ID_TYPE_BOTH. Jul 11 13:21:01 bigbird winbindd[2537634]: [2025/07/11 13:21:01.719035, 1, traceid=1968] ../../source3/winbindd/winbindd_getgroups.c:262(winbindd_getgroups_recv) Jul 11 13:21:01 bigbird winbindd[2537634]: Could not convert sid S-1-5-21-4002244109-2567820566-4139176517-1000: NT_STATUS_NO_SUCH_USER Jul 11 13:22:01 bigbird samba-dcerpcd[787799]: [2025/07/11 13:22:01.881108, 1] ../../source3/rpc_server/rpc_host.c:1813(rpc_worker_exited) Jul 11 13:22:01 bigbird samba-dcerpcd[787799]: rpc_worker_exited: No worker with PID 787804 Jul 11 13:22:01 bigbird winbindd[2537634]: [2025/07/11 13:22:01.975638, 1, traceid=1970] ../../source3/winbindd/wb_queryuser.c:409(wb_queryuser_got_gid) Jul 11 13:22:01 bigbird winbindd[2537634]: Returning NT_STATUS_NO_SUCH_USER Jul 11 13:22:01 bigbird winbindd[2537634]: xid.type must be ID_TYPE_UID or ID_TYPE_BOTH. Jul 11 13:22:01 bigbird winbindd[2537634]: [2025/07/11 13:22:01.975680, 1, traceid=1970] ../../source3/winbindd/winbindd_getgroups.c:262(winbindd_getgroups_recv) Jul 11 13:22:01 bigbird winbindd[2537634]: Could not convert sid S-1-5-21-4002244109-2567820566-4139176517-1000: NT_STATUS_NO_SUCH_USER Jul 11 13:23:01 bigbird winbindd[2537634]: [2025/07/11 13:23:01.071899, 1, traceid=1972] ../../source3/winbindd/wb_queryuser.c:409(wb_queryuser_got_gid) Jul 11 13:23:01 bigbird winbindd[2537634]: Returning NT_STATUS_NO_SUCH_USER Jul 11 13:23:01 bigbird winbindd[2537634]: xid.type must be ID_TYPE_UID or ID_TYPE_BOTH. Jul 11 13:23:01 bigbird winbindd[2537634]: [2025/07/11 13:23:01.071937, 1, traceid=1972] ../../source3/winbindd/winbindd_getgroups.c:262(winbindd_getgroups_recv) Jul 11 13:23:01 bigbird winbindd[2537634]: Could not convert sid S-1-5-21-4002244109-2567820566-4139176517-1000: NT_STATUS_NO_SUCH_USER Jul 11 13:24:01 bigbird winbindd[2537634]: [2025/07/11 13:24:01.166269, 1, traceid=1974] ../../source3/winbindd/wb_queryuser.c:409(wb_queryuser_got_gid) Jul 11 13:24:01 bigbird winbindd[2537634]: Returning NT_STATUS_NO_SUCH_USER Jul 11 13:24:01 bigbird winbindd[2537634]: xid.type must be ID_TYPE_UID or ID_TYPE_BOTH. Jul 11 13:24:01 bigbird winbindd[2537634]: [2025/07/11 13:24:01.166309, 1, traceid=1974] ../../source3/winbindd/winbindd_getgroups.c:262(winbindd_getgroups_recv) Jul 11 13:24:01 bigbird winbindd[2537634]: Could not convert sid S-1-5-21-4002244109-2567820566-4139176517-1000: NT_STATUS_NO_SUCH_USER Jul 11 13:25:01 bigbird winbindd[2537634]: [2025/07/11 13:25:01.261481, 1, traceid=1976] ../../source3/winbindd/wb_queryuser.c:409(wb_queryuser_got_gid) Jul 11 13:25:01 bigbird winbindd[2537634]: Returning NT_STATUS_NO_SUCH_USER Jul 11 13:25:01 bigbird winbindd[2537634]: xid.type must be ID_TYPE_UID or ID_TYPE_BOTH. Jul 11 13:25:01 bigbird winbindd[2537634]: [2025/07/11 13:25:01.261532, 1, traceid=1976] ../../source3/winbindd/winbindd_getgroups.c:262(winbindd_getgroups_recv) Jul 11 13:25:01 bigbird winbindd[2537634]: Could not convert sid S-1-5-21-4002244109-2567820566-4139176517-1000: NT_STATUS_NO_SUCH_USER Jul 11 13:26:01 bigbird winbindd[2537634]: [2025/07/11 13:26:01.359331, 1, traceid=1978] ../../source3/winbindd/wb_queryuser.c:409(wb_queryuser_got_gid) Jul 11 13:26:01 bigbird winbindd[2537634]: Returning NT_STATUS_NO_SUCH_USER Jul 11 13:26:01 bigbird winbindd[2537634]: xid.type must be ID_TYPE_UID or ID_TYPE_BOTH. Jul 11 13:26:01 bigbird winbindd[2537634]: [2025/07/11 13:26:01.359367, 1, traceid=1978] ../../source3/winbindd/winbindd_getgroups.c:262(winbindd_getgroups_recv) Jul 11 13:26:01 bigbird winbindd[2537634]: Could not convert sid S-1-5-21-4002244109-2567820566-4139176517-1000: NT_STATUS_NO_SUCH_USER Jul 11 13:27:01 bigbird samba-dcerpcd[802810]: [2025/07/11 13:27:01.517800, 1] ../../source3/rpc_server/rpc_host.c:1813(rpc_worker_exited) Jul 11 13:27:01 bigbird samba-dcerpcd[802810]: rpc_worker_exited: No worker with PID 802815 Jul 11 13:27:01 bigbird winbindd[2537634]: [2025/07/11 13:27:01.605525, 1, traceid=1980] ../../source3/winbindd/wb_queryuser.c:409(wb_queryuser_got_gid) Jul 11 13:27:01 bigbird winbindd[2537634]: Returning NT_STATUS_NO_SUCH_USER Jul 11 13:27:01 bigbird winbindd[2537634]: xid.type must be ID_TYPE_UID or ID_TYPE_BOTH. Jul 11 13:27:01 bigbird winbindd[2537634]: [2025/07/11 13:27:01.605563, 1, traceid=1980] ../../source3/winbindd/winbindd_getgroups.c:262(winbindd_getgroups_recv) Jul 11 13:27:01 bigbird winbindd[2537634]: Could not convert sid S-1-5-21-4002244109-2567820566-4139176517-1000: NT_STATUS_NO_SUCH_USER
-
Recurring NT_STATUS_NO_SUCH_USER messages in the log
Was the source of this ever identified. I have the exact same behavior. exactly 1 second after every minute I get: Jul 11 13:21:01 bigbird winbindd[2537634]: [2025/07/11 13:21:01.719001, 1, traceid=1968] ../../source3/winbindd/wb_queryuser.c:409(wb_queryuser_got_gid) Jul 11 13:21:01 bigbird winbindd[2537634]: Returning NT_STATUS_NO_SUCH_USER Jul 11 13:21:01 bigbird winbindd[2537634]: xid.type must be ID_TYPE_UID or ID_TYPE_BOTH. Jul 11 13:21:01 bigbird winbindd[2537634]: [2025/07/11 13:21:01.719035, 1, traceid=1968] ../../source3/winbindd/winbindd_getgroups.c:262(winbindd_getgroups_recv) Jul 11 13:21:01 bigbird winbindd[2537634]: Could not convert sid S-1-5-21-4002244109-2567820566-4139176517-1000: NT_STATUS_NO_SUCH_USER Jul 11 13:22:01 bigbird samba-dcerpcd[787799]: [2025/07/11 13:22:01.881108, 1] ../../source3/rpc_server/rpc_host.c:1813(rpc_worker_exited) Jul 11 13:22:01 bigbird samba-dcerpcd[787799]: rpc_worker_exited: No worker with PID 787804 Jul 11 13:22:01 bigbird winbindd[2537634]: [2025/07/11 13:22:01.975638, 1, traceid=1970] ../../source3/winbindd/wb_queryuser.c:409(wb_queryuser_got_gid) Jul 11 13:22:01 bigbird winbindd[2537634]: Returning NT_STATUS_NO_SUCH_USER Jul 11 13:22:01 bigbird winbindd[2537634]: xid.type must be ID_TYPE_UID or ID_TYPE_BOTH. Jul 11 13:22:01 bigbird winbindd[2537634]: [2025/07/11 13:22:01.975680, 1, traceid=1970] ../../source3/winbindd/winbindd_getgroups.c:262(winbindd_getgroups_recv) Jul 11 13:22:01 bigbird winbindd[2537634]: Could not convert sid S-1-5-21-4002244109-2567820566-4139176517-1000: NT_STATUS_NO_SUCH_USER Jul 11 13:23:01 bigbird winbindd[2537634]: [2025/07/11 13:23:01.071899, 1, traceid=1972] ../../source3/winbindd/wb_queryuser.c:409(wb_queryuser_got_gid) Jul 11 13:23:01 bigbird winbindd[2537634]: Returning NT_STATUS_NO_SUCH_USER Jul 11 13:23:01 bigbird winbindd[2537634]: xid.type must be ID_TYPE_UID or ID_TYPE_BOTH. Jul 11 13:23:01 bigbird winbindd[2537634]: [2025/07/11 13:23:01.071937, 1, traceid=1972] ../../source3/winbindd/winbindd_getgroups.c:262(winbindd_getgroups_recv) Jul 11 13:23:01 bigbird winbindd[2537634]: Could not convert sid S-1-5-21-4002244109-2567820566-4139176517-1000: NT_STATUS_NO_SUCH_USER Jul 11 13:24:01 bigbird winbindd[2537634]: [2025/07/11 13:24:01.166269, 1, traceid=1974] ../../source3/winbindd/wb_queryuser.c:409(wb_queryuser_got_gid) Jul 11 13:24:01 bigbird winbindd[2537634]: Returning NT_STATUS_NO_SUCH_USER Jul 11 13:24:01 bigbird winbindd[2537634]: xid.type must be ID_TYPE_UID or ID_TYPE_BOTH. Jul 11 13:24:01 bigbird winbindd[2537634]: [2025/07/11 13:24:01.166309, 1, traceid=1974] ../../source3/winbindd/winbindd_getgroups.c:262(winbindd_getgroups_recv) Jul 11 13:24:01 bigbird winbindd[2537634]: Could not convert sid S-1-5-21-4002244109-2567820566-4139176517-1000: NT_STATUS_NO_SUCH_USER Jul 11 13:25:01 bigbird winbindd[2537634]: [2025/07/11 13:25:01.261481, 1, traceid=1976] ../../source3/winbindd/wb_queryuser.c:409(wb_queryuser_got_gid) Jul 11 13:25:01 bigbird winbindd[2537634]: Returning NT_STATUS_NO_SUCH_USER Jul 11 13:25:01 bigbird winbindd[2537634]: xid.type must be ID_TYPE_UID or ID_TYPE_BOTH. Jul 11 13:25:01 bigbird winbindd[2537634]: [2025/07/11 13:25:01.261532, 1, traceid=1976] ../../source3/winbindd/winbindd_getgroups.c:262(winbindd_getgroups_recv) Jul 11 13:25:01 bigbird winbindd[2537634]: Could not convert sid S-1-5-21-4002244109-2567820566-4139176517-1000: NT_STATUS_NO_SUCH_USER Jul 11 13:26:01 bigbird winbindd[2537634]: [2025/07/11 13:26:01.359331, 1, traceid=1978] ../../source3/winbindd/wb_queryuser.c:409(wb_queryuser_got_gid) Jul 11 13:26:01 bigbird winbindd[2537634]: Returning NT_STATUS_NO_SUCH_USER Jul 11 13:26:01 bigbird winbindd[2537634]: xid.type must be ID_TYPE_UID or ID_TYPE_BOTH. Jul 11 13:26:01 bigbird winbindd[2537634]: [2025/07/11 13:26:01.359367, 1, traceid=1978] ../../source3/winbindd/winbindd_getgroups.c:262(winbindd_getgroups_recv) Jul 11 13:26:01 bigbird winbindd[2537634]: Could not convert sid S-1-5-21-4002244109-2567820566-4139176517-1000: NT_STATUS_NO_SUCH_USER Jul 11 13:27:01 bigbird samba-dcerpcd[802810]: [2025/07/11 13:27:01.517800, 1] ../../source3/rpc_server/rpc_host.c:1813(rpc_worker_exited) Jul 11 13:27:01 bigbird samba-dcerpcd[802810]: rpc_worker_exited: No worker with PID 802815 Jul 11 13:27:01 bigbird winbindd[2537634]: [2025/07/11 13:27:01.605525, 1, traceid=1980] ../../source3/winbindd/wb_queryuser.c:409(wb_queryuser_got_gid) Jul 11 13:27:01 bigbird winbindd[2537634]: Returning NT_STATUS_NO_SUCH_USER Jul 11 13:27:01 bigbird winbindd[2537634]: xid.type must be ID_TYPE_UID or ID_TYPE_BOTH. Jul 11 13:27:01 bigbird winbindd[2537634]: [2025/07/11 13:27:01.605563, 1, traceid=1980] ../../source3/winbindd/winbindd_getgroups.c:262(winbindd_getgroups_recv) Jul 11 13:27:01 bigbird winbindd[2537634]: Could not convert sid S-1-5-21-4002244109-2567820566-4139176517-1000: NT_STATUS_NO_SUCH_USER
-
Plex Docker Container keeping drive from spinning down
Sorry for the delay, didn't see your response until now. The problem was that there was no file activity for the plugin to report. It was purely a misconfiguration of the transcode path in plex that, for some reason, did not exist. I believe that plex was constantly trying to use the transcode temp directory to process a show on my tv share, and couldn't. It never actually read the show's file, but it must have been inspecting the directory or file attributes or something and keeping the drive active.
-
Disable docker settings without deleting them
Great example miicar. One of the things I loved about using docker compose was that my configuration was self documenting. Commenting out options served as part of that record, along with any comments I added along the way.
-
Plex Docker Container keeping drive from spinning down
I am posting this here for anyone else that experiences this problem as something they can check. Problem: One disk, the one holding my tv share, would never spin down like the rest of my drives. Unraid was registering read activity on the drive. I downloaded the logs from Plex and noticed errors in the Plex Media Server.log related to transcoding. Essentially what had happened is that my transcode configuration in plex was set to use /transcode for temporary data... but that directory didn't exist in the linuxserver.io plex container. I had to add a path to map it /transcode to /tmp on the unraid host and the error went away (I have a lot of ram, would have used a cache share if I didnt) . I suspect that the default path for a new plex deployment would have put it somewhere in the appdata directory, however I was migrating from an older system so the transcode working directory was already stored in the plex database. Anyway, for some reason with the transcode path missing, it kept hitting the drive (but not registering a file read), then failing to start the transcode then trying again later. Just one other thing to look at if your struggling with a drive that won't spin down.
2Confused
Members
-
Joined
-
Last visited