dlandon

That's not the update. I've got one more to release today. Wait for today's update.

I honestly didn't know that would work. Some of the changes recently caused this issue for you. I've made a change that will fix this. It will be in the next release.

The SMART log looks fine. It looks like the read and write time out at the end of large disks is not long enough. I'm making some adjustments to see if this problem can be fixed. Currently testing and will release once that test passes. That will be today. You can do another run on the updated preclear to see if it solves this issue for you. Please post the preclear log on the disk so I can confirm if it is a time out.

You should remove the '/flash/config/plugins/unassigned.devices.preclear/*' files so the plugin will download the files fresh. I think you're re-installing the same corrupted package.

Try adding one of the shares back. You can add the same remote share and it will update the UD settings. I am using a Wireguard connecton to a remote server and it works for me.

I released an update to preclear that was missing some files. I reverted the update as soon as I tried to update and had the issue. I've fixed that and released the update that works.

Delete the ./flash/config/plugins/unassigned.devices.preclear.plg' file and reboot.

You have a routing issue: Aug 3 01:49:58 Tower kernel: CIFS: Attempting to mount \\10.253.0.6\amr0d Aug 3 01:49:58 Tower kernel: CIFS: VFS: Error connecting to socket. Aborting operation. Aug 3 01:49:58 Tower kernel: CIFS: VFS: cifs_mount failed w/return code = -111 Aug 3 01:49:58 Tower unassigned.devices: SMB 1.0 mount failed: 'mount error(111): could not connect to 10.253.0.6Unable to find suitable address. '. Aug 3 01:49:58 Tower unassigned.devices: Share '//10.253.0.6/amr0d' failed to mount. According to the testparm output, your listening interfaces are: interfaces = 192.168.94.69 10.253.0.1 127.0.0.1 Not sure what the problem is because I don't know the configuration of your network.

How are you mounting the shares? Please post diagnostics for more help.

It's difficult for us to help you since LT does not support anything associated with ESXI and we don't know much about it. Since ESXI is mounting Unraid shares with NFS, it would be best to loook at the ESXI for answers. One thing to confirm is that ESXI is mounting the shares with NFSv4. I saw in your log where NFSv4 was being used on a share, so maybe that's not a problem. In general the reliability of NFS connections are affected by the followng: Version of NFS being used. Networking issues. Robust NFS requires a solid network. Options used when mounting NFS clients can affect the reliability of the connection and error recovery.

The reason I asked was to confirm the name lookup. UD seems to be having difficulty resolving names to IP addresses at times.

The disk showed 'Pool' because the drive was formatted without a partition and UD does not know how to handle devices formatted that way. Your solution was a good way to handle it.

Even though your server can be ping'd, UD could not resolve those two server names to IP addresses. Did you ping by server name or IP address? As you found out, you can use either the server name or the IP address in UD. The situation you were in was probably you doing an edit to the config file to get UD to "think" it had resolved the server name. That used to work, but I've been working through a lot of issues with UD that caused problems with character sets that make php fail. The Chinese character set has been particularly challenging. That's why the situation you had failed after a UD update.

No. Let me give you an example. A user has a VM running Linux and passes through a disk for the VM. The VM formats the disk using LVM without a partition. Because Unraid disks all have partitions (including UD), this disk layout isn't understood by UD. UD expects that all disks in Unraid will have a partition. You'll notice that the device settings icon (three gears) doesn't show unless a disk has a partition, so marking a disk as "Passed Through" is not possible. The "Pool" status was added so UD would not perform any operations on the disk or let the User perform any operations. A user just had this situation. That's why this was implemented. Until I can come up with a way to allow the clearing of a disk in this state that guards against a user accidentally losing data, this is the way it will stay.

All, Please update UD and see if it solves your issues.

Probably all of the above.

That's a bug I introduced by accident yesterday. I'll have a fix later today.

Post diagnostics.

If Linux can't see a partition and file system on the disk, UD can't do anything with it. Maybe some of the disk gurus here can suggest a method of fixing the disk partition and file system.

It's better to create the share and specify the IP address instead of the server name if you have those issues.

I just remembered there is a trick that should fix this for you without a reboot, Just add the share as if you were setting it up for the first time and it will update and 'fix' the configuration.

Be sure to turn off auto mount before a reboot or you'll end up back in the same situation.

Fixed in the next release. You will have to remove the remote share and add it back. It will be fixed when the remote share is added back.

Here is what I see in your samba_mounts.cfg file: [//ALSBATH/internal] protocol = "SMB" ip = "192.168.1.45" The 'ip' value is supposed to be 'ALSBATH', and not an IP address. and [//ALSSLEEP/internal] protocol = "SMB" ip = "192.168.1.25" The 'ip' is supposed to be 'ALSSLEEP', and not an IP address. I'm not sure how you got into this situation. UD should never let this happen. I suspect these are both old configurations and UD did something different then. Do the following: Stop your server. Remove the two SMB mounts. Start your server. Add the two shares back and mount them to see if it's all sorted out.

Can you PM me the '/flash/config/plugins/unassigned.devices/samba_mount.cfg' file? Please turn off the UD logging. It is too hard to read the log with the UD messages flooding the log.