dlandon

Not sure what you are asking. You want all UD devices to not show? Show a screen shot of what you are talking about.

There is no file system on the disks, or it is not recognized by UD.

Shutdown is the same no matter how it is triggered. Extend your timeouts. If you have a Windows 10 VM that is updating, it can take a long time to update Windows and shut down. I also recommend Hibernating VMs. They will shut down faster.

I'm not seeing an issue: Filesystem Size Used Avail Use% Mounted on rootfs 7.8G 575M 7.2G 8% /

I see some issues you need to take a look at: Nov 17 19:52:52 nerdyRAID unassigned.devices: Disk with serial '', mountpoint '' is not set to auto mount and will not be mounted... The disk serial number is blank. Look at the UD page and see if there is a device without a serial number. Remove the device from UD if so. Nov 19 04:41:43 nerdyRAID root: Fix Common Problems: Warning: Deprecated plugin checksum.plg ** Ignored Remove this plugin. Nov 19 10:56:39 nerdyRAID apcupsd[30630]: UPS battery must be replaced. Your UPS battery is dead. Your diagnostics log doesn't show a shutdown, so I can't see what is causing a shut down issue. Take a look at this post and see if it applies to you: If you continue to have problems, post the diagnostics generated on shutdown at /flash/logs/.

You are storing your data on a UD mounted disk. I suspect there is a problem with that and the events are being stored in the docker image. You should map your data to an array share. Why are you using a UD disk for events?

UD does not store anything significant in the rootfs. Post your diagnostics.

That screen doesn't look like 1.32.

Yup. That works.

Yes.

Output from '/usr/sbin/virsh list --name --state-running': DanLandon Handyman The last line is a null line. Problem here?

Both VMs are Windows 10. One has a pass through video card. Both VMs have been the same through all rc's. I also see that the Libvirt Hotplug USB plugin is not able to get the VM status. It shows no VMs running.

One VM running. Both running.

II can reproduce this.

I just saw this issue also on rc6 myself. mediaserver-diagnostics-20191116-1806.zip Let me know if there is any testing I can do for you. PM me if you want to work on this off the forum.

Don't use Jumbo frames. Keep MTU at the recommended default - generally about 1400 to 1500. This is probably causing your issues with SMB mounts.

Are you using Jumbo frames in your network?

This is what I see: Nov 13 15:33:00 UNRAIDBackup kernel: CIFS VFS: Server HOMESERVER has not responded in 120 seconds. Reconnecting... This is generally a network issue, but can also be from the remote server going off-line.

It's best to not mess with these files. I suggested in an earlier post that you set the UD Setting for the SMB shares to enable Hidden shares. The shares will not be browseable in Windows. Isn't this what you are looking for?

Sounds like network issues. Post your diagnostics.

Set the smb shares as hidden in UD settings.

It should work.

No one will pay attention to the package installation comments, and I doubt many users even understand what nmap is or does. A package won't be installed by UD unless specified in the plugin, is downloaded using a secure link, and the MD5 checksum is verified. All UD packages are hosted on my secure Github. They are not downloaded randomly from the Internet. I think you are overreacting a bit here. I have added a parameter to the "UD Settings" that will allow you to remove the nmap package if it is that much of a problem for you. It is removed when the array is started, so you have to reboot or stop and start the array for it to take effect. nmap is installed by default when the plugin is installed.

The nmap package was updated by me. The repository was not compromised. This has been discussed ad-nauseum. I removed the package, and then I agreed to leave nmap in as a convenience to users. I won't remove the package from the plugin. Conditional plugin installation is not easy. I'm not sure what could be done except your manual removal.

Working for me. Try again. Might be a temporary issue.