dlandon

Your disk is off line. Bad disk? Cable problem? Get the disk back on line.

That would indicate an issue with the routine that tracks the reads and writes. @bonienl It appears that diskio may have an issue.

The only thing I see is that you have 3 data disks, but have 5 slots for data disks - two unused. I think you set the total slots to 7, but are only using 5.

You can already do that. Click on the double gear icon and there is a switch for RO. I don't see this as being something that UD should be doing. It is an edge case and can be done using manual methods. Disk recovery is not something I care to support.

Post your diagnostics.

Remove the UD plugin and see if the reads and writes continue to increment on the stock UD page.

What is it you are trying to accomplish? I don't understand the use case you are asking for.

Unraid has a routine that tracks reads and writes to all disks. UD gets its information for reads and writes from that routine. It appears that it may be tracking the reads and writes incorrectly on the disk you removed from the array. I can't say if this disk is being included in the parity calculations. Try one thing. Click on the double arrows on the upper right of the UD GUI to refresh the UD disks and see if it clears it up. If not, I would post this issue as a potential bug in the 6.10.0 forum.

Click on the red X and delete the preclear logs.

UD logs to the syslog. There is only one attempt to mount the remote share using NFS: Oct 14 07:31:28 khan unassigned.devices: Mounting Remote SMB/NFS Share '192.168.1.10:/mnt/user/Automation'... Oct 14 07:31:28 khan unassigned.devices: Mount NFS command: /sbin/mount -t 'nfs' -o rw,noacl '192.168.1.10:/mnt/user/Automation' '/mnt/remotes/192.168.1.10_Automation' Oct 14 07:31:28 khan rpcbind[14328]: connect from 127.0.0.1 to getport/addr(status) Oct 14 07:31:28 khan unassigned.devices: NFS mount failed: 'mount.nfs: access denied by server while mounting 192.168.1.10:/mnt/user/Automation '. Oct 14 07:31:28 khan unassigned.devices: Mount of '192.168.1.10:/mnt/user/Automation' failed: 'mount.nfs: access denied by server while mounting 192.168.1.10:/mnt/user/Automation '. It fails to mount because of an access issue on the server. Do you have NFS enabled on the remote server?

Post your diagnostics.

You don't need to use sdX. In Unraid 6.9, UD devices are referenced by a devX device nomenclature that does not change on reboot and remains the same for the UD disk even if it is removed and re-installed. Use that in the command I showed you and UD will mount the device.

You create a script in User Scripts and put the disk mount command in the script at the beginning. /usr/local/sbin/rc.unassigned mount /dev/devX The devX is the device name in the UD page. If the device name is 'Dev 1', then use dev1 as the device to mount.

As far as I know it doesn't do that.

Post your diagnostics.

Click on the Help icon when on the UD page and read about how to mount a UD disk using the devX designation in Unraid 6.9.

Click on the double arrow icon in the upper right of UD and see if the drive is recognized again. If that doesn't work, check your drive seating in he socket.

What are you clicking on and what is the error? Screen shot please. Please post your complete diagnostics.

What weird things are you seeing? What is 'crashing' in UD? UD manages mounting/unmounting remote shares and displays some status on the UD web page. It has no active role in the remote share operation once it is mounted. Is there any chance you are mounting the device with UD and the docker container?

This is used to find SMB and NFS servers when you click on the 'Search for Servers' button when adding a SMB or NFS remote share. That is the only time it is used.

Post your diagnostics.

Working fine for me. You might try a reboot.

Are you talking about a VM vdisk?

In the log snippet above, the iscsi disk is not set to auto mount, so it will have to be mounted manually. Not sure if that was intended. Mounting of UD disks is done on the array started event - array disks are mounted. I believe this includes array, cache, and pool disks. The network might not be available at this time. As I understand the way this works, the iscsi device has to be mounted across the network before UD can mount it. Remote mounts are delayed for up to 30 seconds before they are mounted and wait for the network to be ready. I'm reluctant to delay disk mounts until the network is ready because docker containers and VMs may need disk access before the network is available. A little trick would be to enter this command in a User Script set to run at first array start: sleep 2 /usr/local/sbin/rc.unassigned mount /dev/sdX or devX Try to use devX and not sdX because sdX can change on a reboot. devX will always apply to the same device. Note: 'Dev 1' would be 'dev1', 'Dev 2' would be 'dev2', etc. The sleep time might have to be adjusted depending on the server.

I am not seeing this issue and I'm uncomfortable changing the /tmp permissions. It looks like one of the apps you use might be having an issue writing to the /tmp directory.