dlandon

UD is using the Unraid api to open the LUKS disk: Mar 25 17:52:01 mitchsserver unassigned.devices: Using Unraid api to open the 'crypto_LUKS' device. Is the disk password/pass phrase the same as your array? It appears not because the device was not opened: Mar 25 17:52:03 mitchsserver unassigned.devices: Mount of 'transport_data' failed: 'mount: /mnt/disks/transport_data: special device /dev/mapper/transport_data does not exist. ' You can set a specific password for this disk in UD settings.

Would Sunday this week work better for you?

I could do later so it's your evening if that works better. I do not have a structured job, so I'm very flexible.

I will probably want to do early morning here. 7 or 8 AM. I've asked Tom what tests/data he would like me to do/collect so he can replicate the issue. I don't have SAS hardware so I can't reproduce the problem. He has SAS hardware so he should be able to reproduce.

You need to provide diagnostics and more information on how you are setting up your VMs. Memory, CPUs, machine model, etc.

I'm in the US Central Time Zone. So 5 hours ahead of me?

Next week some time. I need to organize what I need to test and what information I need to collect so we can get this solved. I'll get back to you on a date and time. Where are you located so I can take into account the time difference?

It's by design.

Would you be receptive to a Team Viewer session or access to your server so I can get a first hand look?

This seems to be an Unraid issue and we are looking into it. Can you post a bug report on this?

We haven't been able to reproduce the issue. I noticed you have disk slots that are not assigned to disks. Can you re-do the disk slots to just what is needed for your array? This includes array and pool devices. And give it another shot.

If the disk settings are removed the auto mount defaults to 'off'. You'd have to set it to 'on' to auto mount the disk.

Sounds as if the configuration for the device was deleted or lost from your flash. Did you accidently delete the disk configuration in the Historical devices? It's nothing to worry about. What you did is all you have to do. When this happens nothing is lost on your disk, it's just that UD lost your mount point setting.

Nothing yet.

No, I made a mistake.

You caught me in the middle of releasing the update and there was a missing MD5. Try again.

Manually cleaning up that situation is not easy.

A change was made to UD to not allow a Root Share if disk shares was turned on. It was changed to not enable Root Share unless disk sharing was set to "No". Since "Auto" is the default now (this one got past me as I have an old system with old defaults), UD thinks disk sharing is turned on. The problem with disk sharing being on in a Root Share is a copy from a disk share to a user share can cause problems. I also found in my testing that deleting files when disk shares is turned on crashed shfs when the recycle bin plugin was running. Probably the best answer here is to enable the "Add Root Share" button and show a message in the first dialog about turning off disk sharing so a user can make that change.

I'll set it to 125 in the next release.

It's sort of an arbitrary setting - just picked a relatively large number. How many characters do you need?

You have disk sharing turned on. You cannot have a root share while disk sharing is on.

Correct. You'll find that NFSv4 is much more reliable and robust. It's possible the issues are on the old NAS end.

This is the error I see that relates to your issue: Mar 23 07:52:03 Tower unassigned.devices: Error: shell_exec(/bin/df '/mnt/remotes/VEDA_Media' --output=size,used,avail | /bin/grep -v '1K-blocks' 2>/dev/null) took longer than 5s! ### [PREVIOUS LINE REPEATED 2 TIMES] ### This is from the server dropping of-line or more likely a network issue. You are also running 6.9 and you are using NFSv3 which has a lot of issues with remote shares being dropped. I order to use NFSv4 that is a lot more robust, you need to be running 6.10-RC3 or above and set NFSv4 in the UD Settings, You have some other issues going on here also: Mar 23 07:48:17 Tower kernel: traps: lsof[19515] general protection fault ip:14672eb76a9e sp:dbff8b74eba941f error:0 Mar 23 07:48:17 Tower kernel: traps: lsof[19616] general protection fault ip:14d601371a9e sp:50744c1256c0c217 error:0 Mar 23 07:48:17 Tower kernel: traps: lsof[19172] general protection fault ip:14aa3dc2ba9e sp:91585a64f396a3e8 error:0 Mar 23 07:48:17 Tower kernel: traps: lsof[20207] general protection fault ip:14df2b7c7a9e sp:5b116e228ef7db7f error:0 Mar 23 07:48:17 Tower kernel: in libc-2.30.so[14d601352000+16b000] Mar 23 07:48:17 Tower kernel: in libc-2.30.so[14aa3dc0c000+16b000] I have no idea what these are, but are probaby related because the remote share dropped off-line right after these log entries.

Post your diagnbostics.

The button is greyed out when you have disk shares enabled. When disk shares are enabled, you can't create a root share. They conflict and certain operations will crash shfs. You can have disk shares or a root share, but not both.