dlandon

Set up cache_dirs to only include the folders you really need to be scanned. Don't use the default settings. It will end up scanning everything causing the issue you see.

Post your diagnostics so I can see how your system is set up.

The method for determining if a remote server share is available has changed from a ping to checking if the port is open for SMB on the remote server. Check that SMB is enabled on your remote server. Also, be sure port 445 is open on the remote server and it is not being blocked by tail scale or a firewall.

Do the following: Post diagnostics. Click on the double arrows icon in the upper right of the UD page.

If it were me, I'd boot in safe mode and verify SMB was working, then add back plugins and dockers until it stops.

Yes. That won't change the configuration, but will update the system and might be worth a try. I would do this of the two choices.

That looks like it might be a port issue. SMB uses porrt 445. Is there a chance it's being blocked somewhere or in use by a docker or VM somehow? It's very close to port 443 used by https://.

I'm actually in Texas, US of A. I really don't see anything in the diagnostics that necessarily indicates an SMB issue. I'm leaning towards a network/routing issue. I see a few things that should be checked/confirmed: Gateway is 192.168.50.1 but DNS server is 192.168.50.5. Is this correct? It appears the router is supplying the Unraid IP because Unraid is setup to use DHCP? You have said you can ping and log into Unraid so I'm confused why SMB wouldn't work, especially when using the IP address. There is a domain defined - 'loesle'. I suspect this may have been from using AD at some point and is left over. You might try re-configuring SMB Settings. Change a setting and the apply it to regenerate the config file. Do the same for your network settings. As a side note, your access to Unraid is limited to http://. Redo the 'Management Access" settings and enable https://.

Allowing all of the timeouts in UD to be programmable would not be practical. There is no way short of testing this timeout on every possible remote server there is to know the right timeout. The latest version of UD increases the time out to 15 seconds.

There are several things that can affect SMB performance. Some of these things are: Network issues. SMB configuration. Unraid array configuration. I've seen a lot of mis-configured and poor network configurations. This can have an impact on what appears to be SMB issues. The biggest issue with networking I see is users trying to set up Jumbo frames and don't get it right. The way you have your shares set up can affect performance. The "Allocation Method" for distributing files in the array can have an impact. I believe the "High-water" method tends to be faster. As for SMB configuration, Unraid configures SMB to be most compatible. Making the SMB Extras adjustments suggested above can help in a particular situation, but would not be the "most compatible". The "store dos attributes = no" setting turns off the following settings if they are on: map archive = Yes map hidden = No map readonly = no map system = No These are the default Unraid settings, so the only one that is changed is the "map archive". This is the DOS file system archive bit. As for the "ea support = no", this disables extended file attributes. Extended file attributes are used on xfs and btrfs file systems in Linux and turning this off may impact their operation in Unraid depending on what applications are using the Unraid files and if they need extended attributes. So while I appreciate that maximum SMB speed is desireable, applying these "tweaks" to Unraid is not in the best in the interest of compatibility. You are free to do these tweaks in SMB Extras for your particular needs with the understanding of the potential downside. The calls for action "why don't the Unraid devs fix this", is a tough one for Limetech: Samba is open source software that Limetech has no control over. The Samba team has to pretty much reverse engineer SMB because Microsoft is not that forthcomming about SMB functionaliy. Limetech configures SMB the best it can based on keeping the most compatibility. If we can come up with SMB configurations that can help with responsiveness and maintain compatibility, we can definitely implement that. There is one SMB setting I've implemented in UD that might help. If someone can spin up a UD disk and share it with SMB and let me konw if the browsing is improved I can work on implementing that in core Unraid. The setting is: vfs objects = dirsort An SATA disk would be best because USB disks tend to be slower. Be sure to have MacOS compatibility turned off because it blocks this setting. You can't set this manually in SMB Extras because it overwrites other "vfs objects" settings in SMB since SMB Extras are global settings. The downside to the setting is that there is more processing time to sort the directories. I suspect this is similar to the Windows indexing. EDIT: Another setting to try is "Case-sensitive Names" in Share Settings. Read the setting Help by clicking on the setting description and see if a different setting will help.

Format the disk as an encrypted disk.

Neither and it's not a bug. Unraid assigns unassigned disks the 'devX' designation. UD changes the 'devX' to 'Dev X' to make it a little clearer. Given a little time and UD should update the 'dev1' on the GUI.

I'm not seeing how this is a UD problem. Enlighten me.

That's what FIle Activity does.

Special characters can cause issues with php. Try to avoid using a '+' in your passwords.

That timer is the time to wait before starting to mount the remote shares. This insures the network is ready, it has nothing to do with the time to mount shares. No, it's hard coded. Post your disgnostics so I can be sure to come up with the correct solution.

There is not enough performance on a flash drive to run a VM, and any USB connected device will suffer from performance and reliability issues.

Just did. It will be in the next reelease of UD.

Post diagnostics.

You don't need it. Use the alias you assign and then the device for all commands is 'name=alias'. In the case of the detach command, 'name-alias' does work. I see in the UD page it is not documented in the help that the alias can be used. I'll correct that. Edit: In your case use: /usr/local/sbin/rc.unassigned detach name=Backup1

BIOS.

Remove the ipmi plugin and contact the plugin author about the php errors.

When you use the built in device script, the device is passed to the script as $DEVICE. If you have a stand alone or User Script, the alias 'name=' always works as the device for all the commands. The serial is long and very cumbersome. The alias name is a lot easier. The sdX and devX do change. That's why $DEVICE is passed in as an environment variable to the device script. You can use $DEVICE in the built in device script. UD handles the proper device assignment. The alias name works for the consistentcy you are looking for. There is no reason to implement the serial number for the commands.

Be sure to set up cache_dirs to only cache the shares that you want included. If you don't specify the included shares, it will cache anything it finds at /mnt/. Things like the system share don't need to be cached and will definitely put a load on cache_dirs.

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.