dlandon

Update UD and see if UD doesn't allow you to unmount the remote share that is offline. If not, post a screen shot.

Update UD and see if the disk stats are correct.

I'm working on something that might help with this.

Currently UD uses 'df' to get the used and free space. I'm working on a fix for this on zfs disks.

Are you sure the NICs are running at full speed? And nothing is slowing them down like a switch that can't handle that speed?

Try doing a Docker force update and see if it will clear up.

In the latest log (probably after a reboot) I see out of memory errors: Apr 27 23:25:42 Galactica kernel: qbittorrent-nox invoked oom-killer: gfp_mask=0x8c40(GFP_NOFS|__GFP_NOFAIL), order=0, oom_score_adj=0 Apr 27 23:25:42 Galactica kernel: CPU: 8 PID: 53137 Comm: qbittorrent-nox Tainted: P O 6.1.79-Unraid #1 Apr 27 23:25:42 Galactica kernel: Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021 Apr 27 23:25:42 Galactica kernel: Call Trace: Apr 27 23:25:42 Galactica kernel: <TASK> Apr 27 23:25:42 Galactica kernel: dump_stack_lvl+0x44/0x5c Apr 27 23:25:42 Galactica kernel: dump_header+0x4a/0x211 Apr 27 23:25:42 Galactica kernel: oom_kill_process+0x80/0x111 Apr 27 23:25:42 Galactica kernel: out_of_memory+0x3b3/0x3e5 Apr 27 23:25:42 Galactica kernel: mem_cgroup_out_of_memory+0x7c/0xb2 Apr 27 23:25:42 Galactica kernel: try_charge_memcg+0x44a/0x5ad Apr 27 23:25:42 Galactica kernel: charge_memcg+0x31/0x79 Apr 27 23:25:42 Galactica kernel: __mem_cgroup_charge+0x29/0x41 Apr 27 23:25:42 Galactica kernel: __filemap_add_folio+0xc6/0x358 Apr 27 23:25:42 Galactica kernel: ? lruvec_page_state+0x46/0x46 Apr 27 23:25:42 Galactica kernel: filemap_add_folio+0x37/0x91 Apr 27 23:25:42 Galactica kernel: __filemap_get_folio+0x1b8/0x213 Apr 27 23:25:42 Galactica kernel: pagecache_get_page+0x13/0x63 Apr 27 23:25:42 Galactica kernel: alloc_extent_buffer+0x12d/0x38b Apr 27 23:25:42 Galactica kernel: ? _raw_spin_unlock+0x14/0x29 Apr 27 23:25:42 Galactica kernel: read_tree_block+0x21/0x7f Apr 27 23:25:42 Galactica kernel: read_block_for_search+0x220/0x2a1 Apr 27 23:25:42 Galactica kernel: btrfs_search_slot+0x737/0x829 Apr 27 23:25:42 Galactica kernel: ? slab_post_alloc_hook+0x4d/0x15e Apr 27 23:25:42 Galactica kernel: btrfs_lookup_csum+0x5b/0xfd Apr 27 23:25:42 Galactica kernel: btrfs_lookup_bio_sums+0x1bf/0x463 Apr 27 23:25:42 Galactica kernel: btrfs_submit_data_read_bio+0x4a/0x76 Apr 27 23:25:42 Galactica kernel: submit_one_bio+0x8a/0x9f Apr 27 23:25:42 Galactica kernel: submit_extent_page+0x342/0x37e Apr 27 23:25:42 Galactica kernel: ? insert_state+0x96/0xa0 Apr 27 23:25:42 Galactica kernel: btrfs_do_readpage+0x444/0x4b5 Apr 27 23:25:42 Galactica kernel: extent_readahead+0x209/0x255 Apr 27 23:25:42 Galactica kernel: ? btrfs_repair_one_sector+0x28d/0x28d Apr 27 23:25:42 Galactica kernel: read_pages+0x4a/0xf7 Apr 27 23:25:42 Galactica kernel: page_cache_ra_unbounded+0x10e/0x151 Apr 27 23:25:42 Galactica kernel: filemap_fault+0x2ea/0x52f Apr 27 23:25:42 Galactica kernel: __do_fault+0x2d/0x6b Apr 27 23:25:42 Galactica kernel: __handle_mm_fault+0xa22/0xcf9 Apr 27 23:25:42 Galactica kernel: handle_mm_fault+0x13d/0x20f Apr 27 23:25:42 Galactica kernel: do_user_addr_fault+0x2c3/0x48d Apr 27 23:25:42 Galactica kernel: exc_page_fault+0xfb/0x11d Apr 27 23:25:42 Galactica kernel: asm_exc_page_fault+0x22/0x30 Apr 27 23:25:42 Galactica kernel: RIP: 0033:0x120b350 Apr 27 23:25:42 Galactica kernel: Code: Unable to access opcode bytes at 0x120b326. Apr 27 23:25:42 Galactica kernel: RSP: 002b:00007ffc808b67c0 EFLAGS: 00010297 Apr 27 23:25:42 Galactica kernel: RAX: 0000000000000e22 RBX: 00001497696099c0 RCX: 0000000000007efa Apr 27 23:25:42 Galactica kernel: RDX: 000000000000b07f RSI: 000000000000bea1 RDI: 00001497696099c0 Apr 27 23:25:42 Galactica kernel: RBP: 00000000bea0bea0 R08: 0000000000003ea1 R09: 0000000000000000 Apr 27 23:25:42 Galactica kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 Apr 27 23:25:42 Galactica kernel: R13: 0000000000000000 R14: 000000000000bea0 R15: 0000000000000001 Apr 27 23:25:42 Galactica kernel: </TASK> Apr 27 23:25:42 Galactica kernel: memory: usage 67108864kB, limit 67108864kB, failcnt 218213 Apr 27 23:25:42 Galactica kernel: swap: usage 0kB, limit 9007199254740988kB, failcnt 0 Apr 27 23:25:42 Galactica kernel: Memory cgroup stats for /docker/a55f23731cbd1afb5813865a068d4041a7865466bd153a03af53ce809dcfd99d: Apr 27 23:25:42 Galactica kernel: anon 68568096768 Apr 27 23:25:42 Galactica kernel: file 5349376 Apr 27 23:25:42 Galactica kernel: kernel 145981440 Apr 27 23:25:42 Galactica kernel: kernel_stack 311296 Apr 27 23:25:42 Galactica kernel: pagetables 134897664 Apr 27 23:25:42 Galactica kernel: sec_pagetables 0 Apr 27 23:25:42 Galactica kernel: percpu 43160 Apr 27 23:25:42 Galactica kernel: sock 49152 Apr 27 23:25:42 Galactica kernel: vmalloc 8192 Apr 27 23:25:42 Galactica kernel: shmem 0 Apr 27 23:25:42 Galactica kernel: file_mapped 61440 Apr 27 23:25:42 Galactica kernel: file_dirty 0 Apr 27 23:25:42 Galactica kernel: file_writeback 0 Apr 27 23:25:42 Galactica kernel: swapcached 0 Apr 27 23:25:42 Galactica kernel: anon_thp 633339904 Apr 27 23:25:42 Galactica kernel: file_thp 0 Apr 27 23:25:42 Galactica kernel: shmem_thp 0 Apr 27 23:25:42 Galactica kernel: inactive_anon 68568047616 Apr 27 23:25:42 Galactica kernel: active_anon 40960 Apr 27 23:25:42 Galactica kernel: inactive_file 5210112 Apr 27 23:25:42 Galactica kernel: active_file 0 Apr 27 23:25:42 Galactica kernel: unevictable 0 Apr 27 23:25:42 Galactica kernel: slab_reclaimable 3497792 Apr 27 23:25:42 Galactica kernel: slab_unreclaimable 7024936 Apr 27 23:25:42 Galactica kernel: slab 10522728 Apr 27 23:25:42 Galactica kernel: workingset_refault_anon 0 Apr 27 23:25:42 Galactica kernel: workingset_refault_file 286517 Apr 27 23:25:42 Galactica kernel: workingset_activate_anon 0 Apr 27 23:25:42 Galactica kernel: workingset_activate_file 11529 Apr 27 23:25:42 Galactica kernel: workingset_restore_anon 0 Apr 27 23:25:42 Galactica kernel: workingset_restore_file 6757 Apr 27 23:25:42 Galactica kernel: workingset_nodereclaim 0 Apr 27 23:25:42 Galactica kernel: pgscan 1891072 Apr 27 23:25:42 Galactica kernel: pgsteal 289212 Apr 27 23:25:42 Galactica kernel: pgscan_kswapd 11489 Apr 27 23:25:42 Galactica kernel: pgscan_direct 1879583 Apr 27 23:25:42 Galactica kernel: pgsteal_kswapd 6198 Apr 27 23:25:42 Galactica kernel: pgsteal_direct 283014 Apr 27 23:25:42 Galactica kernel: pgfault 2162763532 Apr 27 23:25:42 Galactica kernel: pgmajfault 671 Apr 27 23:25:42 Galactica kernel: pgrefill 84168 Apr 27 23:25:42 Galactica kernel: pgactivate 57604 Apr 27 23:25:42 Galactica kernel: pgdeactivate 69255 Apr 27 23:25:42 Galactica kernel: pglazyfree 0 Apr 27 23:25:42 Galactica kernel: pglazyfreed 0 Apr 27 23:25:42 Galactica kernel: thp_fault_alloc 193490 Apr 27 23:25:42 Galactica kernel: thp_collapse_alloc 2534 Apr 27 23:25:42 Galactica kernel: Tasks state (memory values in pages): Apr 27 23:25:42 Galactica kernel: [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name Apr 27 23:25:42 Galactica kernel: [ 69548] 0 69548 109 13 24576 0 0 s6-svscan Apr 27 23:25:42 Galactica kernel: [ 69801] 0 69801 54 7 24576 0 0 s6-supervise Apr 27 23:25:42 Galactica kernel: [ 69803] 0 69803 51 1 24576 0 0 s6-linux-init-s Apr 27 23:25:42 Galactica kernel: [ 69824] 0 69824 54 6 24576 0 0 s6-supervise Apr 27 23:25:42 Galactica kernel: [ 69825] 0 69825 54 5 24576 0 0 s6-supervise Apr 27 23:25:42 Galactica kernel: [ 69826] 0 69826 54 6 24576 0 0 s6-supervise Apr 27 23:25:42 Galactica kernel: [ 69827] 0 69827 54 7 24576 0 0 s6-supervise Apr 27 23:25:42 Galactica kernel: [ 69835] 0 69835 52 6 24576 0 0 s6-ipcserverd Apr 27 23:25:42 Galactica kernel: [ 69957] 0 69957 407 14 40960 0 0 busybox Apr 27 23:25:42 Galactica kernel: [ 53137] 99 53137 16811420 16740057 134750208 0 0 qbittorrent-nox Apr 27 23:25:42 Galactica kernel: oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=a55f23731cbd1afb5813865a068d4041a7865466bd153a03af53ce809dcfd99d,mems_allowed=0,oom_memcg=/docker/a55f23731cbd1afb5813865a068d4041a7865466bd153a03af53ce809dcfd99d,task_memcg=/docker/a55f23731cbd1afb5813865a068d4041a7865466bd153a03af53ce809dcfd99d,task=qbittorrent-nox,pid=53137,uid=99 Apr 27 23:25:42 Galactica kernel: Memory cgroup out of memory: Killed process 53137 (qbittorrent-nox) total-vm:67245680kB, anon-rss:66960228kB, file-rss:0kB, shmem-rss:0kB, UID:99 I don't understand this because you have a large amount of memory. I would do these things: Remove the older version of cache_dirs and install the newest version. If it is misconfigured, it can cache too much stuff like remote shares. With the new cache_dirs, you only specify shares to be cached. All others are excluded. Reboot in safe mode, re-install UD and test to see if you have the issue with the remote share. If things are working at this point, add your Dockers back one at a time. Be sure to check all your path mappings. If you misconfigure a mapping it can result in stuff getting written to the wrong place - i.e not to a device.

Your log is flooded with these messages indicating a problem with the remote share credentials: May 29 09:11:22 Unraid-Server kernel: CIFS: VFS: \\192.168.188.20 Send error in SessSetup = -13 May 29 09:11:27 Unraid-Server kernel: CIFS: Status code returned 0xc000006d STATUS_LOGON_FAILURE Do the following: Reboot your server. It looks like your tmpfs may be full. Upgrade your server to 6.12.10. Sort out the credentials on your SMB remote share. I recommend you remove your remote shares and then add them back using the server name and not the IP address and sort out the credentials.

If you are using UD to mount a rootshare, it will manage everything for you and you don't need any SMB Extra setings. In fact you'll probably break SMB. If you are creating your own rootshare by editing SMB Extras, that is not supported.

You might have an issue with your flash drive. Post the Unraid diagnostics.

Post ud_diagnostics. Go to a command line, type 'ud_diagnostics' and then post the /flash/logs/ud_diagnostics.zip file here.

You will need to post diagnostics for additional help.

You are having a network/server issue: May 25 20:09:33 Tower unassigned.devices: Warning: shell_exec(/bin/df '/mnt/remotes/TOWER2_UnRaid' --output=size,used,avail | /bin/grep -v '1K-blocks' 2>/dev/null) took longer than 10s! You have Jumbo frames set on one NIC: May 25 19:51:06 Tower root: Fix Common Problems: Warning: Jumbo Frames detected on eth0 In order to use Jumbo frames, you need to set it up for all your network. Having it only on one NIC is problematic. Set the MTU back to the default on eth0.

Follow these steps: Go to Settings->SMB and turn on "Enhanced macOS interoperability:". The Array has to be stopped before you can make this change. Start the Array. Go to Shares->your share->SMB Security Settings and choose one of the Time Machine selections for Export. Fill in the amount of space desired for Time Machine backups. It's the "Time Machine volume size limit:" field. Because of a quirk in Samba, this volume size limit will be the size of the entire share. Hope this helps.

UD is checking the online status in the background. While on the UD page, click the double arrow icon and the online status will be cleared and UD will check and refresh the page remote share status within 15 seconds. If that doesn't work for you, post the UD_diagnostics and I'll look into it.

Go to Tools->PHP Settings and see if the log shows any errors or warnings.

They are still there: I don't know why they are missing for you. Do you have the latest versions of UD and UD Preclear?

UD will not install on Unraid older that 6.11. The "Unassigned Devices" you are seeing on the tab is the stock Unassigned Devices and not the plugin.

What version of Unraid are you running?

If the disk is showling as "Precleared" you are good to go. Your server shutdown after the preclear finished.

I was working on a docker years ago, but gave it up as it ended up taking way too much time. Someone may have forked it, but I don't know.

In looking at the issue, a fix would be quite troublesome beause when the plugin is updated, the tracking of any existing preclear operations would potentially be lost and the preclear page would not be able to update the preclear operation This also affects UD tracking the preclear operation. I'm actually considering not doing anything here for the following reasons: As I mentioned, the tracking of any running preclears would be affected. This only seems to happen on USB bays and USB is really not robust enough for preclearing, especially multiple drives. You can get around this problem you are having by installing the binhex preclear docker. It will allow you to preclear by device.

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.

I see the problem. I'll need to see what can be done about it.

Can you post ud_diagnostics? Go to a command line and do 'ud_diagnostics' then post the /boot/logs/ud_diagnostics.zip.