dlandon

The issue has already been fixed in Unassigned Devices Next, which is an independent continuation of the original Unassigned Devices project.

If you'd like to use the fix now, install both Unassigned Devices Next and Unassigned Devices Plus Next. Installation instructions and releases are available here: https://github.com/dlandon/unassigned.devices-next

The Plus plugin provides the formatting support, including exFAT.

The ports may be open, but with SMB disabled, nothing shoud be responding on those the ports.

This is the way Unraid works.  It does a forced shutdown after a set amount of time that can be configured.  The issue that we run into (this is what happened to UD), is several Linux commands will hang and never fail or time out.  Some examples are 'stat', 'df', 'lsof', and 'fuser' when a mount point is unresponsive.  A forced shutdown cannot happen when one of these Lnux commands is hung.  The only answer, which is what I had to do, is to time out the command hanging UDF so it would eventually fail and not hang.
 
The best we can do is to continue to find and fix these issues.  There has been a lot of time invested in UD to prevent this kind of issue when a remote server goes offline and is not responsive.  It's an incredible challenge to handle all the different cases from the varied remote servers users connect with.

This is known and will be fixed in the next update of 7.0.

There are new settings in Unraid 7.0 that may help this:
Go to Settings->Global Share Settings and increase the "Number of fuse File Descriptors:".  I would start by doubling the default. Go to Settings->NFS and increase the "Number of Threads:" from the default of 8. These two things will probably help.

All you have to do is select 'Array' and save the changes.   In an earlier version of Unraid, the 'Cache' pool was presumed to be there, but in 7.0.0, a verification was added to check the Secondary Pool.  This situation was ignored is earlier versions of Unraid but now generates an error.

I've done some testing and it appears that UD is handling the name with a space correctly, but when mounting a remote share, CIFS doesn't recognize the name.  I'm looking at some options in case UD is not handling the credentials correctly, but it appears a space in the name won't work.  I would recommend not using a space in credentials in either the name or the password.

The check icon is whan a filesystem check can be performed . The "1" indocates partition 1. The log icon will be active when a log is available to view. The pencil indicates you can click on the mountpoint text to change the mountpoint.

This is what is causing your issues:
Dec 12 18:08:35 BusyBee kernel: NFS: server NEO.LOCAL error: fileid changed Dec 12 18:08:35 BusyBee kernel: fsid 0:105: expected fileid 0x90200023f1474bb, got 0xad000000017aa6 Dec 12 18:08:35 BusyBee kernel: NFS: server NEO.LOCAL error: fileid changed Dec 12 18:08:35 BusyBee kernel: fsid 0:105: expected fileid 0x90100000e3d07e3, got 0xad000000017aa4 Dec 12 18:08:35 BusyBee kernel: NFS: server NEO.LOCAL error: fileid changed Dec 12 18:08:35 BusyBee kernel: fsid 0:105: expected fileid 0x90100038ba83239, got 0xad000000017aa2  
Try by fixing these problems:
Dec 12 18:10:04 BusyBee root: Fix Common Problems: Warning: Docker application binhex-readarr has volumes being passed that are mounted by Unassigned Devices, but they are not mounted with the slave option Dec 12 18:10:04 BusyBee root: Fix Common Problems: Warning: Docker application Radarr has volumes being passed that are mounted by Unassigned Devices, but they are not mounted with the slave option Dec 12 18:10:04 BusyBee root: Fix Common Problems: Warning: Docker application Sonarr has volumes being passed that are mounted by Unassigned Devices, but they are not mounted with the slave option Dec 12 18:10:04 BusyBee root: Fix Common Problems: Warning: Docker application tdarr has volumes being passed that are mounted by Unassigned Devices, but they are not mounted with the slave option  

That is a browser problem that does not show the dropwown correctly we are seeing with Chrome and Brave.  Try a different browser.  This will be fixed in the next release of Unraid.
 
The blank in the first screen shot next to 'clash' means it is available.
 
The 'Not Available' in the second screen shot means if has gone off-line.

You are using Jumbo frames:
Nov 21 16:00:18 Cube root: Fix Common Problems: Warning: Jumbo Frames detected on eth0 ** Ignored Nov 21 16:00:18 Cube root: Fix Common Problems: Warning: Jumbo Frames detected on eth6 ** Ignored We do not recommend that because it is a challenge to get it set up correctly on your network.  It really doesn't do anything to improve your network throughput these days because the NIC cards are much better at handling LAN traffic, and it causes issues when not done correctly.
 
Set all your NIC cards back to the default mtu.

Click on the mount point when it is not mounted and you can then change it.

These messages in your log:
May 17 08:22:35 Tower unassigned.devices: Warning: shell_exec(/bin/df '/mnt/remotes/DATASTATION_CloudNAS' --output=size,used,avail | /bin/grep -v '1K-blocks' 2>/dev/null) took longer than 10s! May 17 08:22:45 Tower unassigned.devices: Warning: shell_exec(/bin/df '/mnt/remotes/DATASTATION_media' --output=size,used,avail | /bin/grep -v '1K-blocks' 2>/dev/null) took longer than 10s! May 17 08:23:05 Tower kernel: CIFS: VFS: Send error in read = -11  
indicate issues with your network or remote server.  Your server is using only eth0 that is a Realtek.  Realtek NICs can be troublesome on Linux because the drivers are not well maintained.  There may be other issues with your network or remote server, but I would start by trying the following:
Look at the release notes for 6.12.10 here:  Use another of your NICs or set eth0 and another in a bonded situation using backup mode for reliability. Check the logs of your remote server and see if there are any issues there. Reboot your switch, router, etc to rule out network issues.

Has your problem been resolved?

I see the issue and will have a fix later today.

Yes, and none unless you want UD to manage the device again.  Historical devices only remembers device settings so they are restored when a drive is reinstalled.  This is how a auto mounted USB device for backups works.  The settings are remembered in the historical devices so UD knows what to do with the drive when it is re-installed or hot plugged.

This is your rule.  IP address and options.

When mounting NFS remote shares, UD uses a setting to request the server for the latest version of the protocol available.  You can force UD to use NFSv4 settings when mounting NFS shares by setting the "NFS Version to use when Mounting Remote Shares:" to NFSv4.  This disables the NFS request for version feature.
 
There have been some changes in the latest Kernel in 6.12.9 that have probably caused this change in the way this works.

Install UD and detach the drive.  It will then show in the Historical devices.

You have disk errors:
Feb 26 11:06:20 Tower kernel: scsi_io_completion_action: 812 callbacks suppressed Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2596 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2596 Sense Key : 0x2 [current] Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2596 ASC=0x4 ASCQ=0x0 Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2596 CDB: opcode=0x88 88 00 00 00 00 05 10 38 4a f0 00 00 00 08 00 00 Feb 26 11:06:20 Tower kernel: blk_print_req_error: 812 callbacks suppressed Feb 26 11:06:20 Tower kernel: I/O error, dev sdd, sector 21746961136 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 3 Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2597 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2597 Sense Key : 0x2 [current] Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2597 ASC=0x4 ASCQ=0x0 Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2597 CDB: opcode=0x88 88 00 00 00 00 05 10 38 4a f0 00 00 00 08 00 00 Feb 26 11:06:20 Tower kernel: I/O error, dev sdd, sector 21746961136 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 3 Feb 26 11:06:20 Tower kernel: buffer_io_error: 401 callbacks suppressed Feb 26 11:06:20 Tower kernel: Buffer I/O error on dev sdd, logical block 2718370142, async page read Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2598 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2598 Sense Key : 0x2 [current] Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2598 ASC=0x4 ASCQ=0x0 Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2598 CDB: opcode=0x88 88 00 00 00 00 05 10 38 50 e0 00 00 00 08 00 00 Feb 26 11:06:20 Tower kernel: I/O error, dev sdd, sector 21746962656 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 3 Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2599 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2599 Sense Key : 0x2 [current] Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2599 ASC=0x4 ASCQ=0x0 Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2599 CDB: opcode=0x88 88 00 00 00 00 05 10 38 50 e0 00 00 00 08 00 00 Feb 26 11:06:20 Tower kernel: I/O error, dev sdd, sector 21746962656 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 3 Feb 26 11:06:20 Tower kernel: Buffer I/O error on dev sdd, logical block 2718370332, async page read Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2602 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2602 Sense Key : 0x2 [current] Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2602 ASC=0x4 ASCQ=0x0 Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2602 CDB: opcode=0x88 88 00 00 00 00 05 10 38 56 d0 00 00 00 08 00 00 Feb 26 11:06:20 Tower kernel: I/O error, dev sdd, sector 21746964176 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 3 Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2603 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2603 Sense Key : 0x2 [current] Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2603 ASC=0x4 ASCQ=0x0 Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2603 CDB: opcode=0x88 88 00 00 00 00 05 10 38 56 d0 00 00 00 08 00 00 Feb 26 11:06:20 Tower kernel: I/O error, dev sdd, sector 21746964176 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 3 Feb 26 11:06:20 Tower kernel: Buffer I/O error on dev sdd, logical block 2718370522, async page read Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2604 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2604 Sense Key : 0x2 [current] Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2604 ASC=0x4 ASCQ=0x0 Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2604 CDB: opcode=0x88 88 00 00 00 00 05 10 38 5c c0 00 00 00 08 00 00 Feb 26 11:06:20 Tower kernel: I/O error, dev sdd, sector 21746965696 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 3 Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2605 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2605 Sense Key : 0x2 [current] Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2605 ASC=0x4 ASCQ=0x0 Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2605 CDB: opcode=0x88 88 00 00 00 00 05 10 38 5c c0 00 00 00 08 00 00 Feb 26 11:06:20 Tower kernel: I/O error, dev sdd, sector 21746965696 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 3 Feb 26 11:06:20 Tower kernel: Buffer I/O error on dev sdd, logical block 2718370712, async page read Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2606 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2606 Sense Key : 0x2 [current] Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2606 ASC=0x4 ASCQ=0x0 Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2606 CDB: opcode=0x88 88 00 00 00 00 05 10 38 62 b0 00 00 00 08 00 00 Feb 26 11:06:20 Tower kernel: I/O error, dev sdd, sector 21746967216 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 3 Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2607 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2607 Sense Key : 0x2 [current] Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2607 ASC=0x4 ASCQ=0x0 Feb 26 11:06:20 Tower kernel: sd 7:0:2:0: [sdd] tag#2607 CDB: opcode=0x88 88 00 00 00 00 05 10 38 62 b0 00 00 00 08 00 00 Feb 26 11:06:20 Tower kernel: I/O error, dev sdd, sector 21746967216 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 3 Feb 26 11:06:20 Tower kernel: Buffer I/O error on dev sdd, logical block 2718370902, async page read Feb 26 11:06:20 Tower kernel: Buffer I/O error on dev sdd, logical block 2718371092, async page read Feb 26 11:06:20 Tower kernel: Buffer I/O error on dev sdd, logical block 2718371282, async page read Feb 26 11:06:20 Tower kernel: Buffer I/O error on dev sdd, logical block 2718371472, async page read Feb 26 11:06:20 Tower kernel: Buffer I/O error on dev sdd, logical block 2718371662, async page read Feb 26 11:06:20 Tower kernel: Buffer I/O error on dev sdd, logical block 2718371852, async page read Feb 26 11:06:22 Tower kernel: sd 7:0:2:0: Power-on or device reset occurred ### [PREVIOUS LINE REPEATED 1 TIMES] ### Feb 26 11:06:24 Tower kernel: sd 7:0:15:0: Power-on or device reset occurred Things to look at:
Power supply. Cabling - power and/or data. If you're running three drives at once, I'd suspect a power supply issue.

Click on the "Array Operation" tab and you'll see a check box to format the disks.  Preclear does not format disks with a file system.

The problem is you can't introduce a 'vfs objects' statement in the SMB Extras because it will be a [global] setting and will affect any other 'vfs objects' in use on the SMB shares.
 
This setting has to be applied to each share and there is currently no way to manually add that on a per share basis in Unraid.
 
I really like this idea and you should post a feature request and I will look into it further and propose it be introduced into the core Unraid if it has merit.

I see several things:
Jan 2 13:17:45 luna shfs: share cache full ### [PREVIOUS LINE REPEATED 117 TIMES] ### /dev/nvme0n1p1 932G 866G 66G 93% /mnt/cache Your cache is very full.
 
You have mounted several Synology shares on Unraid and they are not shared:
Jan 2 13:17:44 luna unassigned.devices: Successfully mounted '//SLACKBOX/downloads' on '/mnt/remotes/SLACKBOX_downloads'. Jan 2 13:17:44 luna unassigned.devices: Device '//SLACKBOX/downloads' is not set to be shared. Jan 2 13:17:45 luna unassigned.devices: Successfully mounted '//SLACKBOX/plex' on '/mnt/remotes/SLACKBOX_plex'. Jan 2 13:17:45 luna unassigned.devices: Device '//SLACKBOX/plex' is not set to be shared. This means the UD mounted remote shares are not shared with SMB.  How are you doing SMB copies?  Are you using the file manager or MC on Unraid to copy files from the local mount point?
 
Some suggestions:
Move files off your cache drive to be sure copies are going to the cache nvme and not directly to the array.  Use the mover to do this. Install a plugin called cache_dirs and set it up to cache only specific shares.  Set the shares as included.  Don't include the nvme cache.  The plugin doesn't help an nvme or other SSD disks. Install a plugin called Tips nd Tweks and set up the disk cache.  The defaults are a good place to start.  The symptoms you are describing seem to be classic disk buffering issues.  Transfers are very fast until the ram buffers fill up, then things slow down while the disk data is written.

When you are testing the recycle bin, be sure the file you create then delete is not zero length.  The recycle bin does not save files of zero length.

This is the issue:
Dec 19 14:44:31 unraid unassigned.devices: Remote Server '192.168.2.140' is offline and remote share 'Backup-Unraid' cannot be mounted. The Synology has to respond to a ping.  The gray orb next 'SMB' is an indication the Synology is not responding.  It should be green.  I think I've seen where users have to enable something on a Synology so it will respond to a ping.