dlandon

If it's smb, enter the credentials when you set it up with ud. The quickest way to do that is to setup the smb share again and it will over write the original one.

I'm finishing up a new feature that allows you to add an alias name to a disk device and then use that name to mount, unmount, and spin down a disk. Using this feature, you can spin down a disk when it is unmounted by changing the device script like this: 'REMOVE' ) # do your stuff here /usr/local/sbin/rc.unassigned spindown name=Scratch After the disk is unmounted the 'REMOVE' event is sent to the device script and at that time the spindown can occur. The caveat is that this only works in 6.9 and later. Here is a screen shot to show how the alias naming works. Don't use the hdparm command on 6.9 and later because it confuses the spin down logic in Unraid.

I suspect that was from a mis-configuration of a docker container. I know the situtation of a duplicate name caused you some stress, but the idea behind UD detecting those kinds of issues is to prevent a bigger issue of potentially losing data. This is an array of the UD devices and their share names. It could given me information about UD perhaps having an issue with checking for duplicates. Bottom line, glad you got it worked out.

You might be onto something there. @JorgeB is the disk and controller whizard. Maybe he can offer some assistance.

That would do it.

What is your disk hardware?

I'm not sure what you are trying to do, but you can get it to be more responsive by using: arp -a SERVER

Try clickking on the double arrows in the upper right corner and see if the device file system will be recognized.

There's no file system on sdj.

Post a screen shot of UD.

Show the results of this command: cat /var/state/unassigned.devices/share_names.json

You have other docker contaoiners installed. Turn them all off, turn off your VMs and see if the disks stop spinning up. If they don't spin up, start dockers and VMs one at a time until you find which one is causing the spin ups. My guess is a misconfigured docker container. Not every disk acces will show in the read or write counters.

The On Demand Governor should not cause kernel panics. Can you show a screen shot of Tips and Tweaks? Also post a diagnostics that includes the time you had kernel panics?

Boot in safe mode, spin down all the disks, let the server run for an hour or so, then post new diagnostics.

Update to 2022.01.15a.

This is fixed in the next release. The situation you got into was a partition on a disk with no file system and marked as passed through. UD grayed out the settings icon when the partition had no file system. This has been changed so the disk settings will show even with no file system. You got yourself painted into a corner.

1. If Linux doesn't recognize the fie system, UD can't deteremine it. 2. I don't think the settings icon should be grayed out. I think it's because there is no file system. I'll have to take a look at this situation.

The macOS interroperability setting is now in UD settings. This is a separate setting from the array share setting. This only pertains to UD devices and is set independent of the array setting. It defaults to off. Once you update UD, you'll be able to work with your exFAT disk. You don't need to make any changes.

New release of UD. You can read the Release Notes for the changes. There are known issues with the 'Dev X' assigments: There is a case where the order in which disk devices are installed, removed, and then re-installed can cause the device to not get assigned a 'Dev X' designation. UD will then mark the device as 'Array' which disables all UD functionality on that device. This will be fixed in 6.10-rc3. There are several ways to handle this. Stop the array and then restart the array. The 'Dev X' designations will be reset. If it's a device you install that is auto mounted, UD will go ahead and execute the device script and there is no problem. Reboot. Geez, I hate to even suggest this. Rebooting to me is a terribe solution. Due to a misunderstanding on my part, I incorrectly stated that the 'Dev X' designations were consistent with the device serial number. They aren't. A fix is coming, but won't be in the first release of 6.10. We are still trying to decide the best way to handle this because UD devices come and go and we have to some how bound the devices so Unraid doesn't track every single device ever installed in UD that may never be installed again. In order to help a bit with the 'Dev X' designations not being consistent, I've added the last 'Dev X' assigned to a device in the 'Historical Devices' section. Because of the way 'Dev X' assignments are made, you will see that the 'Dev X' assignment will generally be consistent with the device serial number.

I woudl start by instaling the "Cache Dirs" plugin and set to include only array shares on spinning disks. Don't let cache dirs cache everything. I gets pretty aggressive. You can use the default settings for everything else. What may be happening is that directories may be being accessed that File Activity doesn't pick up. It's not meant to. If it did the log would be huge and unmanageable. As for the file activity on disk1, any idea why that filw would be opening so often? IYou are using a Plex docker container, try stopping it for a while and see if the disk access stops.

If you post your diagnostics, you'll get better help.

How are you trying to use arp?

Which one got dropped?

Click on the mountpoint 'P02509107' and change it back to the original name. UD did a default mountpoint assignment - not sure why. You should always set the mountpoint so UD remembers it and it is always the same. Set it to something that makes sense to you. You can't count on the default name to always be the same.

Can you post a screen shot of UD and explain what 'name' changed.