dlandon

Please provide diagnostics for further help.

Go to Tools->PHP Settings and see if there are PHP warnings. That can cause a mount fail message. Also use the UD disk check to check the disk.

While not a total solution to your situation, I am implementing a retry on mounting remote shares on server startup. There will be multiple tries (right now I'm thinking 3 times) with the UD "Remote Share Mount Wait Time" timeout setting between tries. This will help some on server startup when the remote server is delayed coming online. I prefer to count on the NFS and CIFS built-in robustness to keep the remote shares active and recover from network and remote server issues.

You can stop the preclear, and then resume it where it left off when you restart the server.

Delay the mounting of remote shares using the UD Setting.

This is in your log: Sep 19 08:50:08 Media kernel: r8169 0000:05:00.0 eth1: RTL8125B, 00:e0:4c:01:2a:19, XID 641, IRQ 33 Sep 19 08:50:08 Media kernel: r8169 0000:05:00.0 eth1: jumbo features [frames: 9194 bytes, tx checksumming: ko] I don't have any Realtek NICs, so I can't tell you how to fix this.

Turn off Jumbo frames on your NICs. It is not necessary these days and offers no speed improvements.

You shouldn't have to change permissions. Explain more of what you are trying to do.

In today's release I've changed some remote share mount options that should help with remote shares going offline. SMB and NFS have some error handling built in to handle these kinds of issues and I prefer to rely on that instead of remounting the remote shares. I've considered something like your remount script, but have never come up with anything I am comfortable with.

Why don't you set the disk passphrase in the UD Settings? The keyfile has to contain text only. There can be no new line at the end.

Are you using private browsing or incognito?

The issue us with the '宝' Chinese character. The Chinese character set is multiple bytes and sometimes one of the bytes causes php to choke. I've fixed this for the next release of UD. To fix it now, edit the /flash/config/plugins/unassigned.devices/iso_config.cfg file and remove all the text, then click on the double arrows icon in the upper right corner of the UD page. This will get the UD page working again.

Go to a command line and type 'ud_diagnostics' and then post the /flash/logs/ud_diagnostics.zip file.

It's been fixed in the latest release of UD. There is unfortunately an issue when working in Chrome Incognito that prevents the saving of UD scripts because of security when using Incognito. If you have issues at other times, go to a command line after a save fails and type 'ud_diagnostics' and post the /flash/logs/ud_diagnostics.zip file.

Is AHCI enabled on the sata controller(s)?

Are you sure hot plug is enabled in the BIOS?

Generally clicking the double arrow icon on the UD page to get udev to re-discover the disks works. If you hotplug a disk while on the preclear webpage, it will take some time to show up because the page doesn't refresh that often.

I'm not sure I understand all this. When you say "delete" do you mean in the Historical Unassigned Devices? As far as recognizing devices, try clicking on the two arrows icon in the upper right of the UD page. This will trigger a udev update and should show any unassigned disks. Do you mean it cannot be mounted? You have a drive that doesn't mount because there is no file system on the disk: Sep 5 15:50:49 Tower unassigned.devices: Partition '/dev/sdd1' does not have a file system and cannot be mounted.

Use Bridge mode for networking and the URL is https://IP:8443/zm. The /zm is required. Port 443 is probably already used on your system. That's why the Docker Container changes it to 8443. Make sure 8443 is not used by another Docker Container.

There are several reasons this can happen: Flash drive corruption. UD config file corruption. Security options in your browser. For example private browsing with Chrome. Look at the message at the bottom of the page next to the buttons. Those happen when you reboot and there is an issue with the plugin installing. Click on "Plugins" and you'll see a plugin error tab. You can delete them. Try the following: Try a different browser. Take the flash drifve to a PC and run a disk check. Unplug the Unassigned USB disk and you'll then see it in the Historical Unassigned Devices list. Click the red X to delete the configuration and start over. Plug the disk back in and try the device settings again.

Do the following: Power down your server. Re-seat the nvme card. Power on and then format the drive. Click on the double arrows in the right hand corner of the UD page if the 'Mount' button is grayed out. I know this sounds strange, but several users have reported re-seating the nvme card has fixed this issue.

I'd say it's probably a situation with your backup software.

Here are the things to check: Be sure NFS on the server where the disk is mounted is enabled in UD settings. Be sure NFS is enabled on the server where the disk is mounted. Be sure the disk 'Share' switch is on. Be sure port 2049 is open through your VPN. This is the port UD checks to be sure the remote server is online and ready to accept NFS connections. Will it work if the VPN is turned off? What version of Unraid is running on the remote server?

No, that doesn't make any difference.

That should not be happening. What is happening is an empty partition from the USB disk is showing up on the internal disk. Udev is confused about the partitions. Here are a few things to try: Start by unmounting both disks, then click on the double arrow icon. Click on each disk check file system icon (check mark by the partition). See if that fixes the issue. Shutdown the server and disconnect the internal disk. See if the USB disk is recognized. If it is, unload the internal disk files and reformat the disk. Copy files back to the internal disk. If not, unload the USB disk and reformat that disk. Use UD to do all the partition removal and reformatting of the disks.