dlandon

Click on the drop down and select the disk to clear the passphrase. The passphrase is by disk. I suppose I could eliminate a passed through encrypted disk from that drop down.

Post diagnostics from 7.0 Beta 3.

There's not. Probably not. Looks like your disks are dropping off-line while mounted,

It looks like your expander is reporting disk partitions incorrectly, or Linux is confused about partiutions. For example: [/dev/sdq] ACTION="add" DEVLINKS="/dev/disk/by-id/ata-HUH728080ALE601_VJGU11NX-part1 /dev/disk/by-id/wwn-0x5000cca261cb613b-part1 /dev/disk/by-label/_VJGU11NX /dev/disk/by-partuuid/ba941532-6339-466e-b184-207d8dca3dc7 /dev/disk/by-path/pci-0000:00:10.0-sas-exp0x50030480004c4cbf-phy26-lun-0-part1 /dev/disk/by-uuid/3d1454c4-d04d-40f4-90ef-07979c3a2eb6" DEVNAME="/dev/sdcq1" DEVPATH="/devices/pci0000:00/0000:00:10.0/host4/port-4:0/expander-4:0/port-4:0:277/end_device-4:0:277/target4:0:315/4:0:315:0/block/sdcq/sdcq1" DEVTYPE="partition" Is reporting partition '/dev/sdcq1' on disk '/dev/sdq'. [/dev/sdcb] ACTION="add" DEVLINKS="/dev/disk/by-id/ata-HUH728080ALE601_VJGU11NX-part1 /dev/disk/by-id/wwn-0x5000cca261cb613b-part1 /dev/disk/by-label/_VJGU11NX /dev/disk/by-partuuid/ba941532-6339-466e-b184-207d8dca3dc7 /dev/disk/by-path/pci-0000:00:10.0-sas-exp0x50030480004c4cbf-phy26-lun-0-part1 /dev/disk/by-uuid/3d1454c4-d04d-40f4-90ef-07979c3a2eb6" DEVNAME="/dev/sdcq1" Is reporting partition '/dev/sdcq1' on disk '/dev/sdcb'. Try downgrading to a version of Unraid that you think may have worked. Also try Unraid 7.0 beta and see if that works. EDIT: So I found this situation is a bug in UD, but not sure how it could cause your issue.

Go to a command line and enter 'ud_diagnostics', then post the '/flash/logs/ud_diagnostics.log'. Also post the Unraid diagnostics.

You can detach the device programatically in a script. Go to the UD page and click on the help icon and look at the rc.unassigned script commands for how to do it. It's also included in the default UD device script, but is commented out. Just be sure the device is fully unmounted first.

Be sure Server B has NFS enabled. Try a clean reboot on Server B and see if it will work.

Go to the settings when the disk is unmounted and save a blank passphrase. It will then be removed from UD.

Post ud_diagnostics by going to a command line and executing the command 'ud_diagnostics' and then post the '/flash/logs/ud_diagnostics.log file'. Also post Unraid diagnostics.

Click on the three gears icon and then click the 'Attach' button. If the device is actually removed, the attach will time out and the message will go away.

Not really. UD devices are used for all kinds of uses that do not involve sharing the disks with SMB or NFS: Backup disk. I have a UD disk I use for Daily backups of my Unraid server. I do not want this disk shared on the network. Periodic backup of the server to be stored off-site. I do this Weekly and Monthly. I do not want these disks shared on the network when installed to make a backup. Downloads and temporary processing. UD disks are used for storing downloads and temporary data that users don't want shared on the network. Docker or Plugin data. I have a security system Docker Container and a UD disk is used to store security camera video. I do not want this shared on the network. UD disks are used like an Array Pool device that can be mounted, unmounted, and removed/installed without shutting down the Array like you'd have to do with a Pool device. The comment in the Best Practices is just a reminder that if you don't need to share devices with SMB, don't, and if you do enable user security to limit who has access to the UD disk. Initially UD was set up to share everything as Public by default. This was changed to require a user to enable security as needed for security.

The 'cache=none' parameter is used to insure consistency in data when multiple clients access the remote share at the same time. There are other settings we can try, but we will have to be sure we don't sacrifice data consistency for speed. Try the 'cache=strict' setting and see if the speed improves. This is a middle ground between consistency and performance. Let me know how that goes, and we can look at other options to see which works best for consistency and speed. EDIT: I learned that the setting for 'cache' is 'strict' when the 'cache=none' is removed. I'm probably going to remove the 'cache=none' in the next release. I'll do some testing.

I don't know of anything that has changed in Samba that would cause your issue with the 'cache' option, but I will investigate.

Go to a command line and enter the command 'ud_diagnostics', then post the /flash/logs/ud_diagnostics.zip file. Also post the Unraid diagnostics.

There is a new setting in UD in Device Settings to set NTFS3 when mounting a disk. The setting applies to individual disks.

That's a new feature for Unraid 7.0. You can ignore that message and I will make a change so it doesn't show.

I made a post in April here providing a potential soluition and asked for some feedback on this issue. Without any responses, I can only assume everything is working. If you are still having issues, you'll need to provide some feedback, otherwise nothing is going to happen.

Update UD and see if it will solve your issue.

Update UD and see if your issues are solved.

I'll have a fix in the next release of UD. If you set the automount switch on, the remote share should auto mount once the online detection is fixed.

I see it. I have that command time out after 1 second. It's too soon.

Give me the output of this command when the mount button is grayed out: bash -c '(echo >/dev/tcp/ZENO.LOCAL/445) &>/dev/null'; echo $? and this: bash -c '(echo >/dev/tcp/ZENO/445) &>/dev/null'; echo $? and this: bash -c '(echo >/dev/tcp/{IP Address of ZENO}/445) &>/dev/null'; echo $? and this: arp -a ZENO and this: arp -a ZENO.LOCAL

I've had this reported several times and I'm beginning to develop a theory of how this happens. When a remote share is added, there is a procedure to determine if the remote server is online that appears to be different than the process to determine if a remote share is on line after it has been added. It's probably related to name resolution. It may be a bit of a challenge for me to fix because I've not been able to reproduce the issue. I'll see if I can figure it out. BTW, you don't need to remove the remote share, just add it and it will overwrite the existing one and should get the same result as removing and adding.

Post the ud_diagnostics.zip file.

What is happening is the remote server is not seen by UD to be ready to accept SMB connections. UD checks that the port for SMB is open on that server. When you remove and add back the SMB share, the remote server is checked by UD and found to be on line and the 'Mount' button is enabled. Normally UD checks remote servers every 15 seconds for being online. You can click on the double arrows icon in the the upper right of the UD page to force an update instead of removing and adding back the remote share. The next release of UD will attempt to mount remote shares three times with the UD "Remote Share Wait Time" between tries. The remote online status will be checked before each try to mount remote shares to be sure it is current.