Gico

Accessing the server through multiple names is intentional. It allows me to connect to the server in Windows using different user IDs, enabling separation of permissions across different applications. These messages only started appearing in a recent 7.xx version. I was accessing the server the same way before, and there were no messages.

How can I stop these DFS errors from filling up my logs? I searched the forum, disabled NetBIOS, and kept WSD enabled, but the errors are still appearing. Feb 20 09:42:55 Juno smbd[273155]: [2026/02/20 09:42:55.992568, 0] ../../source3/smbd/msdfs.c:120(parse_dfs_path_strict) Feb 20 09:42:55 Juno smbd[273155]: parse_dfs_path_strict: Hostname JunoL is not ours. Feb 20 09:42:58 Juno smbd[273155]: [2026/02/20 09:42:58.797829, 0] ../../source3/smbd/msdfs.c:120(parse_dfs_path_strict) Feb 20 09:42:58 Juno smbd[273155]: parse_dfs_path_strict: Hostname JunoL is not ours. Feb 20 09:45:06 Juno smbd[273155]: [2026/02/20 09:45:06.081588, 0] ../../source3/smbd/msdfs.c:120(parse_dfs_path_strict) Feb 20 09:45:06 Juno smbd[273155]: parse_dfs_path_strict: Hostname JunoL is not ours.

I had been running a parity sync for several days. I paused it, stopped the array, and then started it again. The parity sync restarted from zero — why did that happen? juno-diagnostics-20260125-1925.zip

I rebooted into safe mode. Rebuild performance there is excellent — around 100 MB/s compared to just 35–40 MB/s during a normal boot. I may investigate the cause later. Unfortunately, there’s no option to simply disable plugins, only to remove and reinstall them. In this situation, is there a way to back up the current plugin configuration/data before removing them? There is no disk activity in safe mode after cancelling the rebuild. juno-safemode-diagnostics-20260123-1216.zip

I’m copying disk22 (the emulated disk) to a pool, which is causing activity on the array disks. However, I don’t understand why disk17 is also being written to. In any case, this process is expected to take about 36 hours.

I’ll test it once the copy of disk22 completes, which should be in about two days. By “testing,” do you mean performing the same action—cancelling the automatic data rebuild? I can do that and provide the diagnostics, but immediately afterward I’ll run New Config and rebuild the parity. I noticed too that the smaller disks are no longer participating. Now the 18 TB disks are no longer spinning, while the 20 TB disks are. Based on this, there isn’t much time left for this to continue, since disk 17 is 22 TB—so it won’t last much longer anyway.

I configured a pause within 30-minute in the Parity Check plugin, but when the pause time was reached, nothing changed—the disks remained active. It seems that the plugin is indeed not detecting the active array operation. Regarding the suggestion that something else might be causing the disk activity: disk17 is being written to at the same speed that the other disks are being read, which strongly suggests the activity is related. Configured the plugin "No" on the three "Use increments for...", stopped the array, started it, cancelled the data rebuild, and still disks activity remains. juno-diagnostics-20260117-1640.zip Anyway when I'll be done copy disk22 content I'll new-config the array and this issue will probably be gone.

I set the plugin to pause the parity rebuild at 15:10 my time (12 minutes ago), but it didn't. Any ideas why? juno-diagnostics-20260116-1520.zip

I will do that within a few hours, but this data rebuild seems to have a will of its own. At times it appears to pause (based on disk activity) and then resume without any action on my part. I tried starting the Sync button again—data rebuild began, I then cancelled it, yet the process continues regardless.

This is not a good time for me to run tests. I currently have no redundancy, and restoring it is my top priority. (For future testing, this may be related to my array current status—one disk emulated/uninstalled and another that dropped from the array and was later deassigned and reassigned.) Is there a way to stop the parity build via the CLI? The option is no longer available in the GUI.

I canceled the data rebuild after the disks dropped from the array and I reassigned one of them. However, all array disks continue to show read/write activity as if the rebuild is still in progress. Screenshot juno-diagnostics-20260115-1825.zip

Thank you. I was aware that the parity swap option exists, but I assumed that a fully valid parity and healthy array disks were required in order to use it. However, this procedure implies that: The array would be unavailable during the copy phase (approximately 4–5 days), which is a significant drawback for me. As I understand it, the data would be rebuilt with only one parity drive replaced initially. I would then need to replace the second parity drive as well, which would trigger another parity build. Even if it were possible to replace the second parity drive and perform the copy simultaneously or sequentially, the array would still remain unavailable for an extended period. Overall, this approach does not appear to save much time compared to my original plan.

I’m experiencing several issues with my Unraid array. The array contains 30 devices, of which 5 are currently unassigned. Two 24 TB parity drives. Disk22 (24 TB) dropped from the array several days ago and is confirmed faulty. I will RMA this drive. Disk17 dropped tonight. Its SMART data is clean, and I’m confident nothing has been written to it since it dropped. I intend to avoid any writes to this disk. Diagnostices attached. I do not have a spare 24 TB drive. However, I do have two 28 TB drives that were originally planned to replace the 24 TB parity drives. Unraid does not allow me to replace disk22 with a 28 TB drive because it exceeds the size of the current parity drives, even though I am willing to leave the extra 4 TB unused until both parity drives are upgraded to 28 TB. I want to replace disk22 and upgrade both parity drives to 28 TB. I canceled the rebuild of disk17, as I believe it is unnecessary. My plan is: Copy the contents of disk22 to a ZFS pool (estimated ~1 week). Perform New Config, preserving all assignments. Replace both parity drives with 28 TB disks. Assign one of the former parity drives as the replacement for disk22. Start the array. Copy data from the ZFS pool back to the new disk22. Steps 5 and 6 may be slow if run concurrently, so I may wait until the parity build completes before starting step 6. This process may take up to three weeks to complete. Any suggestions for a safer, faster, or cleaner approach? juno-diagnostics-20260114-0905.zip

My parity disk is 24 TB, and I live in an apartment that’s prone to power outages. A full parity sync takes about 6–7 days. I was hoping that if a power outage occurred during a parity sync, this plugin would allow the process to resume from where it left off once the power came back. Unfortunately, that’s not the case: I was already 5 days into a sync when the power went out, and afterward I had to restart the entire sync from the beginning. Right now, when the UPS shuts the server down, the parity sync is canceled instead of paused. That means I always have to start a new sync from scratch after power is restored. I configured the plugin to run daily with a 5-minute pause, thinking it would resume the parity sync after a power outage. Questions: Is there a way to pause a parity check during a power outage rather than having it canceled? Is there any way to tweak the system so that I can continue a parity sync from a known percentage (e.g., 73%) that was already reached in the previous run?

OK got it: It's a plugin setting, not the Unraid syslog setting.

The previous server shutdown was not clean, which explains the lack of restart information. However, after the restart, a new parity sync began. Why would pausing it, stopping the array, then starting it cause the parity sync's resumption to still depend on an abnormal shutdown that occurred before the parity sync started? The plugin is still in Testing mode. I changed "Mirror syslog to flash" to "Yes," and "Copy syslog to flash on shutdown" was already set to "Yes." Is this sufficient? I've replaced the UPS batteries, so there shouldn't be any more abnormal shutdowns. However, if the parity sync starts from the beginning again, I'll post the diagnostics. I'm still facing an issue with read errors during the sync, which I haven't resolved yet. Attached are the diagnostics from after the first parity sync. juno-diagnostics-20241007-1420.zip

Diagnostics attached. First parity-sync was in Debug mode, than another one in Testing mode. Both reported as cancelled, but I paused them, then stopped the server. Edit: After the second time, when I started the array, I could (manually) resume the parity sync. This suggests that the plugin works correctly in Testing mode, but not in other modes, at least on my server. Edit2: BTW, I also have diagnostics from after the first array stop, when the plugin was in Debug mode. Let me know if you need me to post it. juno-diagnostics-20241007-1442.zip

I didn't notice such a warning, but it might have happened because my UPS batteries only last a few minutes. I paused the parity sync, backed up the flash drive, stopped the array, yet still received the "Parity Sync/Data rebuild cancelled" message, and this parity sync is listed as cancelled in the plugin history. Why is that? It was a clean stop. Unfortunately syslog was full so nothing was written to it. I'm planning to replace the UPS batteries, restore the flash from the backup, and hopefully be able to resume the parity sync.

My flat experiences frequent power outages, occurring every few days. I recently changed my array configuration and started a parity-sync, configuring the plugin to use increments for Parity-Sync/Data Rebuild operations. However, after a recent power outage, the sync restarted from 0%. Any idea why this happened? The only explanation I can think of is that I configured the plugin during the ongoing parity-sync operation, so perhaps the changes only take effect for parity syncs initiated after the configuration was applied. Below are the history entries for the last two incomplete parity-syncs. Action Date Size Duration Speed Status Errors Elapsed Time Increments Parity-Sync 2024-10-03, 17:01:01 (Thursday) 24 TB 16 hr, 1 min, 15 sec Unavailable Canceled 17189393 Parity-Sync 2024-10-01, 07:16:14 (Tuesday) 24 TB 6 day, 16 hr, 1 min, 10 sec 41.7 MB/s Canceled 3443815 6 day, 16 hr, 1 min, 10 sec 1 Edit: 17:01:01 is the time of the last power outage. Maybe I'm reading it incorrectly, but the shutdown initiated by the UPS seems to trigger a cancellation of the parity-sync instead of pausing it.

It's not. When I put it in my main machine as parity 2 and it went through a successful Parity Sync process.

Same. First time it happens below byte 22000000000000. So if I put the disk in the array as parity, can this be ok? Maybe it's related only to the plugin's zeroing process? Alternatively if the disk is no good, I'll still will get an error, and then I guess I'll replace it. Apr 25 01:57:41 preclear_disk_ZGG46T0A_10918: Zeroing: dd output: 21998195441664 bytes (22 TB, 20 TiB) copied, 98221.6 s, 224 MB/s Apr 25 01:57:41 preclear_disk_ZGG46T0A_10918: Zeroing: dd output: 10490310+0 records in Apr 25 01:57:41 preclear_disk_ZGG46T0A_10918: Zeroing: dd output: 10490310+0 records out Apr 25 01:57:41 preclear_disk_ZGG46T0A_10918: Zeroing: dd output: 21999774597120 bytes (22 TB, 20 TiB) copied, 98233.6 s, 224 MB/s Apr 25 01:57:41 preclear_disk_ZGG46T0A_10918: dd process hung at 21999776694272, killing ... Apr 25 01:57:41 preclear_disk_ZGG46T0A_10918: Zeroing: zeroing the disk started 2 of 5 retries... Apr 25 01:57:41 preclear_disk_ZGG46T0A_10918: Continuing disk write on byte 21999774597120 Apr 25 02:13:39 preclear_disk_ZGG46T0A_10918: Zeroing: dd output: Apr 25 02:13:39 preclear_disk_ZGG46T0A_10918: dd process hung at 0, killing ... Apr 25 02:13:39 preclear_disk_ZGG46T0A_10918: Zeroing: zeroing the disk started 3 of 5 retries... Apr 25 02:13:39 preclear_disk_ZGG46T0A_10918: Zeroing: emptying the MBR. Apr 25 08:01:50 preclear_disk_ZGG46T0A_10918: Zeroing: progress - 25% zeroed @ 270 MB/s

After upgrading UD Preclear to 2024.04.23 when starting a preclear it offers to resume or start new one, and what ever I select it goes to "starting" mode and stays in that mode. Uninstalled and reinstalled the plugin and it's the same. Unraid 6.12.6. While installing I got the following message, which corresponds with @Rozella's post. "Checking tmux operation... tmux is not working properly"

Same happens with a different HBA: LSI PCI-E card. Is there anyway to limit the available disk size to 22000000000000? I can also try zeroing it on my main machine (the one in my signature). Apr 23 14:23:27 preclear_disk_ZGG46T0A_10952: Zeroing: dd output: 22000449880064 bytes (22 TB, 20 TiB) copied, 98245.7 s, 224 MB/s Apr 23 14:23:27 preclear_disk_ZGG46T0A_10952: dd process hung at 22000451977216, killing ... Apr 23 14:23:27 preclear_disk_ZGG46T0A_10952: Zeroing: zeroing the disk started 2 of 5 retries... Apr 23 14:23:27 preclear_disk_ZGG46T0A_10952: Continuing disk write on byte 22000449880064 Apr 23 14:31:52 preclear_disk_ZGG46T0A_10952: Zeroing: dd output: Apr 23 14:31:52 preclear_disk_ZGG46T0A_10952: dd process hung at 0, killing ... Apr 23 14:31:52 preclear_disk_ZGG46T0A_10952: Zeroing: zeroing the disk started 3 of 5 retries... Apr 23 14:31:52 preclear_disk_ZGG46T0A_10952: Zeroing: emptying the MBR.

Yes always stops somewhere after 22000000000000. Disk is attached to an onboard controller and the MB (Supermicro H12SSL-i ) has another one that seems to be identical. I will try with an HBA card.

A new 22TB disk, Zeroing is on it's 5th attempt after 4 failed ones. Any reason for that / anything I can do/check? Preclearing only to test the disk. Destined to be a parity disk. Apr 19 20:11:16 preclear_disk_ZGG46T0A_12945: Zeroing: dd output: 10486367+0 records out Apr 19 20:11:16 preclear_disk_ZGG46T0A_12945: Zeroing: dd output: 21991505526784 bytes (22 TB, 20 TiB) copied, 100595 s, 219 MB/s Apr 19 20:11:16 preclear_disk_ZGG46T0A_12945: Zeroing: dd output: 10487104+0 records in Apr 19 20:11:16 preclear_disk_ZGG46T0A_12945: Zeroing: dd output: 10487104+0 records out Apr 19 20:11:16 preclear_disk_ZGG46T0A_12945: Zeroing: dd output: 21993051127808 bytes (22 TB, 20 TiB) copied, 100607 s, 219 MB/s Apr 19 20:11:16 preclear_disk_ZGG46T0A_12945: Zeroing: dd output: 10487838+0 records in Apr 19 20:11:16 preclear_disk_ZGG46T0A_12945: Zeroing: dd output: 10487838+0 records out Apr 19 20:11:16 preclear_disk_ZGG46T0A_12945: Zeroing: dd output: 21994590437376 bytes (22 TB, 20 TiB) copied, 100619 s, 219 MB/s Apr 19 20:11:16 preclear_disk_ZGG46T0A_12945: Zeroing: dd output: 10488577+0 records in Apr 19 20:11:16 preclear_disk_ZGG46T0A_12945: Zeroing: dd output: 10488577+0 records out Apr 19 20:11:16 preclear_disk_ZGG46T0A_12945: Zeroing: dd output: 21996140232704 bytes (22 TB, 20 TiB) copied, 100631 s, 219 MB/s Apr 19 20:11:16 preclear_disk_ZGG46T0A_12945: Zeroing: dd output: 10489298+0 records in Apr 19 20:11:16 preclear_disk_ZGG46T0A_12945: Zeroing: dd output: 10489298+0 records out Apr 19 20:11:16 preclear_disk_ZGG46T0A_12945: Zeroing: dd output: 21997652279296 bytes (22 TB, 20 TiB) copied, 100643 s, 219 MB/s Apr 19 20:11:16 preclear_disk_ZGG46T0A_12945: Zeroing: dd output: 10490037+0 records in Apr 19 20:11:16 preclear_disk_ZGG46T0A_12945: Zeroing: dd output: 10490037+0 records out Apr 19 20:11:16 preclear_disk_ZGG46T0A_12945: Zeroing: dd output: 21999202074624 bytes (22 TB, 20 TiB) copied, 100655 s, 219 MB/s Apr 19 20:11:16 preclear_disk_ZGG46T0A_12945: Zeroing: dd output: 10490768+0 records in Apr 19 20:11:16 preclear_disk_ZGG46T0A_12945: Zeroing: dd output: 10490768+0 records out Apr 19 20:11:16 preclear_disk_ZGG46T0A_12945: Zeroing: dd output: 22000735092736 bytes (22 TB, 20 TiB) copied, 100667 s, 219 MB/s Apr 19 20:11:16 preclear_disk_ZGG46T0A_12945: dd process hung at 22000737189888, killing ... Apr 19 20:11:16 preclear_disk_ZGG46T0A_12945: Zeroing: zeroing the disk started 4 of 5 retries... Apr 19 20:11:16 preclear_disk_ZGG46T0A_12945: Continuing disk write on byte 22000735092736 Apr 19 20:19:41 preclear_disk_ZGG46T0A_12945: Zeroing: dd output: Apr 19 20:19:41 preclear_disk_ZGG46T0A_12945: dd process hung at 0, killing ... Apr 19 20:19:41 preclear_disk_ZGG46T0A_12945: Zeroing: zeroing the disk started 5 of 5 retries... Apr 19 20:19:41 preclear_disk_ZGG46T0A_12945: Zeroing: emptying the MBR. Apr 20 02:29:32 preclear_disk_ZGG46T0A_12945: Zeroing: progress - 25% zeroed @ 265 MB/s Apr 20 08:34:41 preclear_disk_ZGG46T0A_12945: Zeroing: progress - 50% zeroed @ 234 MB/s Apr 20 15:34:20 preclear_disk_ZGG46T0A_12945: Zeroing: progress - 75% zeroed @ 197 MB/s