dlandon

Look at the disk log and see if there are any log entries relating to disk issues.

Set up a User Script to run on a cron for the time you want and run this command: /usr/local/emhttp/plugins/recycle.bin/scripts/rc.recycle.bin cron &> /dev/null

You can do that, but it will get changed when the recycle bin is restarted, or when you reboot the server.

So the only plugin installed is the sas drive plugin? No. I will need you to do this with the minimum of plugins and a diagnostic.

UD does not see sdf (parity disk) as a hot plugged device. I think we might have an Unraid issue. Can you boot in safe mode, create the issue and then post diagnostics. I can then present this as an Unraid issue with all plugins out of the way to be sure there is not a plugin problem.

I just came across something that I'd like you to try for me: /usr/bin/nmblookup DISKSTATION | /bin/head -n1 | /bin/awk '{print $1}' Execute this command in a console and let me know the outcome. Be careful, this might cause the oom.

There's an issue with the assignment of the devX designations. They aren't consistent and can change. This is something I want to solve, but we haven't found a reasonable solution. It's impractical for Unraid to track all of the devices ever installed in a server by serial number and devX. Let's move to the parity being shown as unassigned. Make that happen and give me diagnostics.

Nice work @JorgeB.

Missing from where? Unless we get to a bare metal Unraid we can't determine where the issue is. I don't see that in the diagnostics. Only dev1 and dev2 are unassigned. I find it hard to believe that dynamix is creating unassigned disks out of the clear blue. It uses the vars dev array to display the unassigned disks. I need the diagnostics so I can see the udev and hotplug activity. You need to slow down and do one thing at a time. It's hard for me to follow when you do things and just give me snippets of logs and files. I can't follow and there are some things I want to try at each step. So let's get back to the issue with the parity disk showing as unassigned. How did you create that issue, and is it repeatable? Create it again if you can, then give me diagnostics and pause there so I can have you do some things.

Eveything looks good. Next thing to try. Remove the following plugins: DevPack.plg. sas-spindown.plg. snapshots.plg. usb_manager.plg. usb_manager_usbip_addon.plg. unassigned.devices.plg. Then run your test. Let's see if one of the plugins is causing the issue. This will let us know if it's a plugin or Unraid. With UD uninstalled you won't see the unassigned disk you install in the Unassigned Devices page or the Dashboard. UD is catching the udev events and triggering Unraid to re-arrange unassigned devices. Unraid won't do it without UD.

So we have made some progress. Now do this: Unplug the Dev 4 device. Go the the UD Settings and set the "Debug Log Level" to "Udev and Hotplug". Plug the Dev 4 device back in. Post diagnostics again. This will log the hot plug events UD tracks. I'm looking to see if a hot plug event is triggering a spin up of the parity disk by mistake.

So the unassigned devices are staying straightened out now. The issue is that the parity disk spins up when an unassigned disk is installed?

I see two unassigned disks. sdb and sdi. I know UD has them right because I can see UD trying to auto mount both of them, but they are not set for auto mount. What does the dashboard show? What does UD show on the UD page?

Thank you. I'm out of ideas.

Can you post your diagnostics? We've added some additional information to the diagnostics that might help me track this down.

Post your diagnostics.

Thanks for the info in a PM. Now let's do a few more things. Go to your Settings->Management Access and show me how you have "Local TLD:" set. Also execute this command at the cli: arp -a DISKSTATION I think I might see something I can do.

I use the 'arp' command and it is known to have some issues - like hangs. Unfortunately, I think this is out of my control.

UD does that by pinging servers to see if the server supports the SMB port. Thanks to Windows and Linux samba changes for security, it has become more difficult to do named lookups unless you enable NetBIOS, which is now considered too insecure to use. Do you have NetBIOS enabled? Another thing I want you to look at is the 'Local TLD:' setting in the Settings->Management Access. Let me know what you have set.

I'd like to do a bit more research. Having UD cause oom issues is not a good thing. Even if the remote share won't work, UD should be robust enough to handle it. Post the output of this command: cat /etc/hosts This will expose some IP addresses. You can PM that to me and not post it on the forum.

I can't answer that. It's a Linux thing. I don't know enough about VMWare disks. The expert at disks is @JorgeB. Maybe he has a suggestion. I could add the mounting of VMWare disks in UD, but I would need a VMWare disk (I don't have one) and a week or so to implement.

There aren't any writes to the /mnt/remotes/ folder because the remote share has not even been mounted. What I suspect is going on is the ping status check to update the remote server online status. If you remember @Squid that's the routine you and I had to troubleshoot when your Windows computer would not mount a remote share. I'm not an expert at all the networking stuff, but I think that routine is stuck in a loop and kills avahi. Remove the share and add it using the IP address instead of the name 'DISKSTATION' and see if the same thing happens.

Windows deals with the VMWare tag on the disk and will mount them as NTFS disks. Linux doesn't recognize them as NTFS because of the VMWare tag. It takes a special Linux package to mount the VMFS disks. This has not been implemented into UD at this time.

What is the remote share you are trying to use? Show a screen shot of the UD page.

Linux sees those disks as VMWare disks. UD does not currently mount those kinds of disks. My suggestion is to put them back into the old server and do a UD remote share mount and transfer the data that way.