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.