nick5429

System: Supermicro X8DTE-F, 24GB ram, Xeon L5640 HBA330, bunch of spinning data drives, 1 out-of-pool SSD for misc tinkering and docker storage At least once a week lately, my system will completely hang and be unresponsive to any input. No unraid networking page, nor even respond to physical keyboard attached. Cursor doesn't blink, "enter" doesn't insert a new console line, numlock doesn't toggle, etc. This time, it happened when I was starting a VM which triggered the OOM process. Frequently other times, it will happen 'randomly' as far as I can tell, though with indications an OOM was involved. I'm not sure this even makes a ton of sense outside of this VM-induced crash today, as generally I run no VMs and just typical collection of dockers with 24GB of RAM. `free -m` would typically show at least 1+GB completely free and ~8GB buffered/cached which could be reclaimed under memory pressure rather than killed-for. Aside: I'm playing around with ZFS pools on the 'cache' mount, but is used only as a data drive/pool. I'm unconcerned about associated reported errors in the syslog. Various zfs things use 10-12GB, but nevertheless -- an OOM event should not cause a complete system hang [especially the more routine 'random' ones that aren't requesting 8GB all at once, which aren't captured here] Diagnostics attached; syslog mirrored to flash and captured in diagnostics Screenshot from IPMI "physical console" showing some killed when hung It looks like process 'unraid-api' gets killed at some point; is that a noteworthy problem? nickserver-diagnostics-20240911-0957.zip

Another temporary workaround which will allow you to examine things while debugging is to increase the size of the "/var/log" ramfs filesystem: # increase tmpfs for logging mount -t tmpfs tmpfs /var/log -o size=1G,remount

I have a proof-of-concept script here which pulls info from Plex's "on deck" API, and remaps the file paths from my docker's paths back into my unraid filesystem paths. I haven't integrated any of this into the actual preloading script You'll need to get your plex API token; a "temporary" token is pretty easy and straightforward to get, see https://support.plex.tv/articles/204059436-finding-an-authentication-token-x-plex-token/ IIRC, these temporary tokens still maybe last 'a while'/long enough to be useful beyond just development? #!/bin/bash # Plex server details PLEX_URL="http://192.168.1.10:32400" API_KEY="" # Define the path mappings declare -A path_map=( ["/Movies/"]="/mnt/user/Movies/" ["/TV-Kids/"]="/mnt/user/TV-Kids/" ["/TV-CurrentShows/"]="/mnt/user/TV-CurrentShows/" # Add more mappings as needed ) # Define the video file extensions video_ext='avi|mkv|mov|mp4|mpeg' # Function to remap file paths remap_path() { local original_path="$1" for prefix in "${!path_map[@]}"; do if [[ "$original_path" == "$prefix"* ]]; then # Replace the prefix with the mapped path echo "${original_path/$prefix/${path_map[$prefix]}}" return fi done # If no mapping found, return the original path echo "$original_path" } # Function to get "On Deck" items from Plex and process file paths get_ondeck() { local plex_url="$1" local api_key="$2" # Query the On Deck list from Plex local plex_on_deck_url="$plex_url/library/onDeck?X-Plex-Token=$api_key" # Get the list of On Deck items (assumed response in XML format) local response=$(curl -s "$plex_on_deck_url") # Parse the XML response and extract the full file paths from <Part> tags local video_files=() while IFS= read -r line; do # Dynamically create a regular expression using the video_ext variable local file_path=$(echo "$line" | grep -oP "(?<=file=\")[^\"]+\.($video_ext)\"") if [[ -n "$file_path" ]]; then # Remove trailing quote that gets included file_path=$(echo "$file_path" | sed 's/"$//') # Remap the file path using the remap_path function local remapped_file_path=$(remap_path "$file_path") video_files+=("$remapped_file_path") fi done < <(echo "$response" | grep -oP '<Part[^>]*file="[^"]*"') # Output the array elements, one per line printf "%s\n" "${video_files[@]}" } # Get and print the remapped On Deck video files echo "Remapped On Deck video files:" # Capture the output of get_ondeck into an array called "ondeck_files" mapfile -t ondeck_files < <(get_ondeck "$PLEX_URL" "$API_KEY") # Print the remapped file paths printf "%s\n" "${ondeck_files[@]}"

And if that doesn't work, let us know what filesystem you were using. If it was xfs and not working with the mount command above, show the output of this command [changing the /dev/sdd to the device you are working on]: head /dev/sdd | xxd | grep XFSB

I agree completely, and the response here has been pretty indifferent and the issue ignored. Not great. Anyway see my response in the bug, but TL;DR for anyone encountering this: try mounting the partition with -o offset=0, or the disk with -o offset=32768. In my case: mount -t xfs -o offset=0 /dev/sdd1 /tmp/is-disk6/

fwiw this post isn't me; appears somebody else had this same problem:

I'm on 6.12.11 Docker start command shows as: docker run -d --name='binhex-sickchill-fresh' --net='bridge' -e TZ="America/New_York" -e HOST_OS="Unraid" -e HOST_HOSTNAME="nickserver" -e HOST_CONTAINERNAME="binhex-sickchill-fresh" -e 'UMASK'='000' -e 'PUID'='99' -e 'PGID'='100' -l net.unraid.docker.managed=dockerman -l net.unraid.docker.webui='http://[IP]:[PORT:8081]/' -l net.unraid.docker.icon='https://raw.githubusercontent.com/binhex/docker-templates/master/binhex/images/sickchill-icon.png' -p '8091:8081/tcp' -v '/mnt/user/appdata/data':'/data':'rw' -v '/mnt/user':'/media':'rw' -v '/mnt/disks/SanDiskSSD/appdata/binhex-sickchill-fresh':'/config':'rw' 'binhex/arch-sickchill' Manually running /home/nobody/start.sh didn't give me any additional info beyond the prior 'illegal instruction' Redirecting the config/install dir back onto /mnt/user/appdata didn't change anything

A brand new copy of this container with none of the default populated settings changed, into a blank config directory, fails in exactly the same way on my system Copying my full config directory and pointing the latest top of tree version of the LSIO sickchill container at it seems to work

Created by... ___. .__ .__ \_ |__ |__| ____ | |__ ____ ___ ___ | __ \| |/ \| | \_/ __ \\ \/ / | \_\ \ | | \ Y \ ___/ > < |___ /__|___| /___| /\___ >__/\_ \ \/ \/ \/ \/ \/ https://hub.docker.com/u/binhex/ 2024-07-25 14:24:41.201040 [info] Host is running unRAID 2024-07-25 14:24:41.257635 [info] System information Linux 12937845fbd7 6.1.79-Unraid #1 SMP PREEMPT_DYNAMIC Fri Mar 29 13:34:03 PDT 2024 x86_64 GNU/Linux 2024-07-25 14:24:41.311686 [info] PUID defined as '99' 2024-07-25 14:24:41.401049 [info] PGID defined as '100' 2024-07-25 14:24:41.495063 [info] UMASK defined as '000' 2024-07-25 14:24:41.545407 [info] Permissions already set for '/config' 2024-07-25 14:24:41.630897 [info] Deleting files in /tmp (non recursive)... 2024-07-25 14:24:42.005329 [info] Starting Supervisor... 2024-07-25 14:24:42,748 INFO Included extra file "/etc/supervisor/conf.d/sickchill.conf" during parsing 2024-07-25 14:24:42,748 INFO Set uid to user 0 succeeded 2024-07-25 14:24:42,757 INFO supervisord started with pid 7 2024-07-25 14:24:43,759 INFO spawned: 'start-script' with pid 47 2024-07-25 14:24:43,760 INFO reaped unknown pid 8 (exit status 0) 2024-07-25 14:24:44,762 INFO success: start-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) 2024-07-25 14:24:45,028 DEBG 'start-script' stderr output: /home/nobody/start.sh: line 7: 49 Illegal instruction "${install_path}/bin/sickchill" --config /config/config.ini --datadir /config 2024-07-25 14:24:45,028 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 22418072691408 for <Subprocess at 22418073011728 with name start-script in state RUNNING> (stdout)> 2024-07-25 14:24:45,028 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 22418085474448 for <Subprocess at 22418073011728 with name start-script in state RUNNING> (stderr)> 2024-07-25 14:24:45,028 WARN exited: start-script (exit status 132; not expected) 2024-07-25 14:24:45,029 DEBG received SIGCHLD indicating a child quit Docker fails to start I rolled back to binhex/arch-sickchill:2024.2.18-01 a while back; tried again today and it's still failing

Thanks for clarifying It would be great to have this documented much more clearly/prominently and explicitly, since in other places IIRC parallels are/were drawn between the prior concepts of 'cache' and 'main unraid array' as 'pools'. If that were the case, then what I was originally trying to do ought to have been possible

That doesn't, and shouldn't, make a difference. After making your suggested change and rebooting: I don't mean to offend -- but can I get clarity from someone else who confidently knows the correct answer to the core question here? Is this actually possible? I'm surprised that I haven't been able to find anyone else either asking this question or trying but failing to accomplish this.... Diagnostics attached nickserver-diagnostics-20240216-1838.zip

I'm talking above about read-only scenarios where my server has become nearly unusable. The write parity mechanism isn't coming into play. Accessing the data I mentioned above using direct disk shares alleviates many of the problems, but I'm not interested in trying to memorize which shares belong on which disks just to use them without twiddling my thumbs while I wait for a directory listing. # ls -d /mnt/*/www /mnt/disk16/www/ /mnt/user/www/ /mnt/user0/www/ This extremely simple share stored entirely on disk16, and won't mount with 'exclusive access'. Should it be able to, or am I wasting my time trying to get this working with data on the regular unraid pool?

My reading of the exclusive shares and 'pools' concepts in the release notes implied that the 'array' was a pool, largely like any other pool. If I have ALL of the data for a share on a single disk, on the regular unraid array (along with the other usual conditions) -- is it eligible to be mounted as an 'exclusive share'? I have several shares which I have worked to reorganize onto a single disk, inside the regular pool. NFS is disabled both on the shares, and globally. No data for those shares exists on other disks, nor empty directories. The shares still do not mount as 'exclusive share'. Performance even of browsing directories through shfs has gotten atrocious. I can't even stream a single moderate-bitrate video through a user share over samba while simultaneously browsing directories on completely separate disks via user share, without the video skipping and buffering.

Updated, and get no errors on boot with the new version. Haven't testing anything beyond that. But thanks!

Looks like it's the quote returned in 'Model Family' for these drives: root@nickserver:~# /usr/sbin/smartctl --info --attributes -d auto /dev/sdc smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.1.64-Unraid] (local build) Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Family: Toshiba 3.5" MG03ACAxxx(Y) Enterprise HDD Device Model: TOSHIBA MG03ACA300 Serial Number: 64OUKFOJF LU WWN Device Id: 5 000039 59c580e61 Firmware Version: FL1A User Capacity: 3,000,592,982,016 bytes [3.00 TB] Sector Size: 512 bytes logical/physical Rotation Rate: 7200 rpm Form Factor: 3.5 inches Device is: In smartctl database 7.3/5528 ATA Version is: ATA8-ACS (minor revision not indicated) SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is: Tue Feb 6 15:13:57 2024 EST SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000b 100 100 050 Pre-fail Always - 0 2 Throughput_Performance 0x0005 100 100 050 Pre-fail Offline - 0 3 Spin_Up_Time 0x0027 100 100 001 Pre-fail Always - 11608 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 4143 5 Reallocated_Sector_Ct 0x0033 100 100 050 Pre-fail Always - 0 7 Seek_Error_Rate 0x000b 100 100 050 Pre-fail Always - 0 8 Seek_Time_Performance 0x0005 100 100 050 Pre-fail Offline - 0 9 Power_On_Hours 0x0032 001 001 000 Old_age Always - 69664 10 Spin_Retry_Count 0x0033 182 100 030 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 153 191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 120 193 Load_Cycle_Count 0x0032 098 098 000 Old_age Always - 21236 194 Temperature_Celsius 0x0022 100 100 000 Old_age Always - 38 (Min/Max 16/80) 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 220 Disk_Shift 0x0002 100 100 000 Old_age Always - 0 222 Loaded_Hours 0x0032 001 001 000 Old_age Always - 53131 223 Load_Retry_Count 0x0032 100 100 000 Old_age Always - 0 224 Load_Friction 0x0022 100 100 000 Old_age Always - 0 226 Load-in_Time 0x0026 100 100 000 Old_age Always - 195 240 Head_Flying_Hours 0x0001 100 100 001 Pre-fail Offline - 0 I believe this specific problem is here: https://github.com/dlandon/unassigned.devices/blob/master/source/Unassigned.devices.preclear/scripts/rc.diskinfo#L542C1-L544C79 $out = timed_exec(10, "/usr/sbin/smartctl --info --attributes ".$type." ".escapeshellarg($device)." 2>/dev/null"); $info = trim(shell_exec("echo -e \"{$out}\" | grep -v '\[No Information Found\]' | grep -c -e 'Vendor:' -e 'Product:' -e 'Serial Number:' -e 'Device Model:'")); $attr = trim(shell_exec("echo -e \"{$out}\" | grep -c 'ATTRIBUTE_NAME'")); These, and similar, need escapeshellarg()

Two diagnostics along with accompanying physical terminal output screenshots, immediately after a fresh reboot. Both have all my other regular 'stuff' enabled. The only thing that changed between these boots was installing the UD preclear plugin immediately before rebooting.

For me, it appears to be the Unassigned Devices Preclear plugin. I reported it in the author's thread here:

BUG REPORT Something in this plugin is causing error messages to get dumped to the physically attached console/monitor on boot, which do not appear to be shown or logged to syslog or anywhere else I've been able to locate. I narrowed it down to this plugin by removing all plugins, then individually enabling plugins and rebooting until the errors returned. These messages are not generated for me when the plugin is "installed" - only on full reboot. It looks like something is using unsanitized input into a shell command, where the parsing chokes likely on either a single/double quote, or open-parenthesis. I'm not sure if the actual problem is the parens in "Toshiba...(Y) Enterprise HDD" logged to the screen, or some prior parsing step See this thread for someone else with the same problem: https://forums.unraid.net/topic/143922-weird-error-messages-on-console/#comment-1297893

Did you figure out what was causing this issue? I have this as well and been trying to track it down off and on for a year or so, but haven't gone through the effort yet of iteratively enabling plugins. The errors messages for me only log to the physical console, and not to syslog or anywhere else I've found. My hunch is that it has to do with SAS drives. updated edit: I've vaguely suspected unBalance, since I also have problems with unBalance not working right / choking on SAS drives, but these appear related as this problem does not occur with unBalance enabled on boot.

I'm using the same card, and I'm pretty sure my configuration is working for RSS. The "this command must show..." just doesn't account for how the mellanox driver reports its interrupts (maybe only in certain configurations of the card/driver/firmware?). Try: # egrep 'CPU|eth*|mlx' /proc/interrupts On the Windows side, you may also want to run something like the following, in an admin Powershell: > Set-NetAdapterRss -Name "Ethernet_10Gbe" -MaxProcessors 6 -NumberOfReceiveQueues 6 -BaseProcessorNumber 4 -MaxProcessorNumber 16 -Profile Closest I'm not sure why Windows is reporting 'Client RDMA Capable = False' for me; I thought at one point it showed 'True' during my setup/config of the RSS feature, but I might be mis-remembering. Docs seem to indicate that you need the Windows Workstation license for RDMA as a *server*, but not for RDMA *client*, so I'd hoped to be able to get that flipped on as well Though OTOH, I think the ConnectX 3 [non-Pro] require correctly configured PFC or Global Pause in order to function over ethernet/fiber (ie, non-infiniband). This requires support in your switch, too. RoCEv2 (in the ConnectX 3 Pro and beyond) might be more easily managed in that regard

It appears the difference is the '-a' flag. Without '-a', the command I thought was safe appears to be safe: root@nickserver:/mnt/disk4# rsync -v --info=progress2 --remove-source-files /mnt/disk4/death /mnt/disk4/ skipping directory death 0 100% 0.00kB/s 0:00:00 (xfr#0, to-chk=0/0) sent 17 bytes received 12 bytes 58.00 bytes/sec total size is 0 speedup is 0.00 root@nickserver:/mnt/disk4# ls -lha /mnt/disk4/death total 0 drwxrwxrwx 2 root root 66 May 12 11:14 ./ drwxrwxrwx 9 nobody users 142 May 12 11:13 ../ -rw-rw-rw- 1 root root 0 May 12 11:14 myfile1 -rw-rw-rw- 1 root root 0 May 12 11:14 myfile2 -rw-rw-rw- 1 root root 0 May 12 11:14 myfile3 -rw-rw-rw- 1 root root 0 May 12 11:14 myfile4 root@nickserver:/mnt/disk4# rsync -av --info=progress2 --remove-source-files /mnt/disk4/death /mnt/disk4/ sending incremental file list 0 100% 0.00kB/s 0:00:00 (xfr#0, to-chk=0/5) sent 144 bytes received 49 bytes 386.00 bytes/sec total size is 0 speedup is 0.00 root@nickserver:/mnt/disk4# ls -lha /mnt/disk4/death total 0 drwxrwxrwx 2 root root 6 May 12 11:24 ./ drwxrwxrwx 9 nobody users 142 May 12 11:13 ../

This was precisely the intent rsync manpage shows: Nothing got transferred, so nothing should be deleted I'd have sworn that in the past when I was *TRYING* to copy-verify-and-delete data which was duplicated on two different disks (e.g., at times when the mover flaked out and identical data existed on both the cache and the regular array), it completely ignored (and explicitly did not delete) source files which also existed at the destination. But the trial example I just constructed shows different behaviour: root@nickserver:/mnt# ls /mnt/disk4/death myfile1 myfile2 myfile3 root@nickserver:/mnt# ls /mnt/disk5/death myfile1 myfile2 myfile3 myfile4 root@nickserver:/mnt# rsync -av --remove-source-files --info=progress2 -X /mnt/disk4/death^Cmnt/disk5/ root@nickserver:/mnt# rsync -av --remove-source-files --info=progress2 -X /mnt/disk5/death /mnt/disk4/ sending incremental file list death/ death/myfile1 0 100% 0.00kB/s 0:00:00 (xfr#1, to-chk=0/5) death/myfile2 0 100% 0.00kB/s 0:00:00 (xfr#2, to-chk=2/5) death/myfile3 0 100% 0.00kB/s 0:00:00 (xfr#3, to-chk=1/5) death/myfile4 0 100% 0.00kB/s 0:00:00 (xfr#4, to-chk=0/5) sent 309 bytes received 128 bytes 874.00 bytes/sec total size is 0 speedup is 0.00 root@nickserver:/mnt# ls /mnt/disk4/death myfile1 myfile2 myfile3 myfile4 root@nickserver:/mnt# ls /mnt/disk5/death root@nickserver:/mnt#

The unBalance plugin was not giving me sane behavior, so I decided I could just rsync manually on the commandline to accomplish the same thing: moving all the data in a ~7TB share onto a newly-installed, empty 8TB disk -- the new disk is disk6 I ran the following to generate the list of commands I intended to execute: root@nickserver:/mnt/disk6# for i in /mnt/disk* > do > echo rsync -av --remove-source-files --info=progress2 -X "$i/DLs" "/mnt/disk6/" > done rsync -av --remove-source-files --info=progress2 -X /mnt/disk1/DLs /mnt/disk6/ rsync -av --remove-source-files --info=progress2 -X /mnt/disk11/DLs /mnt/disk6/ rsync -av --remove-source-files --info=progress2 -X /mnt/disk12/DLs /mnt/disk6/ rsync -av --remove-source-files --info=progress2 -X /mnt/disk13/DLs /mnt/disk6/ rsync -av --remove-source-files --info=progress2 -X /mnt/disk14/DLs /mnt/disk6/ rsync -av --remove-source-files --info=progress2 -X /mnt/disk15/DLs /mnt/disk6/ rsync -av --remove-source-files --info=progress2 -X /mnt/disk16/DLs /mnt/disk6/ rsync -av --remove-source-files --info=progress2 -X /mnt/disk17/DLs /mnt/disk6/ rsync -av --remove-source-files --info=progress2 -X /mnt/disk18/DLs /mnt/disk6/ rsync -av --remove-source-files --info=progress2 -X /mnt/disk2/DLs /mnt/disk6/ rsync -av --remove-source-files --info=progress2 -X /mnt/disk3/DLs /mnt/disk6/ rsync -av --remove-source-files --info=progress2 -X /mnt/disk4/DLs /mnt/disk6/ rsync -av --remove-source-files --info=progress2 -X /mnt/disk5/DLs /mnt/disk6/ rsync -av --remove-source-files --info=progress2 -X /mnt/disk6/DLs /mnt/disk6/ # unnecessary, but I assessed as harmless rsync -av --remove-source-files --info=progress2 -X /mnt/disk9/DLs /mnt/disk6/ rsync -av --remove-source-files --info=progress2 -X /mnt/disks/DLs /mnt/disk6/ # unnecessary, but I assessed as harmless Not all of these were fully relevant, not all had data on them -- but I briefly evaluated that 'it should be fine anyway'. I copied and pasted all those rsync commands back into my terminal, and walked away for a couple days. When I returned, disk6 had essentially zero data: root@nickserver:/mnt/disk6# du -hs /mnt/disk6 292K /mnt/disk6 My log/alerts showed various other disks decreasing below the warning thresholds as their data was offloaded. Disk6 showed filling up; filling up; filling up to 97% warning threshold -- then 5 minutes later, dropping down to 'normal utilization level' (which appears to effectively be "empty"): 10-05-2022 20:53 Unraid Disk 6 message Notice [NICKSERVER] - Disk 6 returned to normal utilization level H7280A520SUN8.0T_001649PAR4LV_VLKAR4LV_35000cca260bc9574 (sdd) normal 10-05-2022 20:47 Unraid Disk 6 disk utilization Alert [NICKSERVER] - Disk 6 is low on space (97%) H7280A520SUN8.0T_001649PAR4LV_VLKAR4LV_35000cca260bc9574 (sdd) alert 10-05-2022 20:32 Unraid Disk 6 disk utilization Alert [NICKSERVER] - Disk 6 is low on space (96%) H7280A520SUN8.0T_001649PAR4LV_VLKAR4LV_35000cca260bc9574 (sdd) alert 10-05-2022 19:29 Unraid Disk 6 disk utilization Warning [NICKSERVER] - Disk 6 is high on usage (91%) H7280A520SUN8.0T_001649PAR4LV_VLKAR4LV_35000cca260bc9574 (sdd) warning 10-05-2022 18:05 Unraid Disk 4 message Notice [NICKSERVER] - Disk 4 returned to normal utilization level TOSHIBA_DT01ACA300_X3G716ZKS (sdx) normal 10-05-2022 16:28 Unraid Disk 2 message Notice [NICKSERVER] - Disk 2 returned to normal utilization level TOSHIBA_MG03ACA300_54G1KI4TF (sds) normal 10-05-2022 13:38 Unraid Disk 17 message Notice [NICKSERVER] - Disk 17 returned to normal utilization level HUS726060AL5210_NAGZ0EHY_35000cca242369310 (sdk) normal Did I overlook something obvious/stupid in my rsync commands? Was that ` rsync -av --remove-source-files --info=progress2 -X /mnt/disk6/usenet /mnt/disk6/ ` command destructive after all? It shouldn't be, given the description of the --remove-source-files flag (which only deletes successfully transferred source data; and this command should have moved nothing) In related news -- do we have a preferred xfs un-delete tool; ideally which will attempt to preserve filenames as much as possible? I have another empty disk large enough to hold any recovered data....

It doesn't look like this report was ever addressed, and I have this same problem For my case... the target disk I *want* to select has enough free space (7.5TB out of 8TB) to move the entire usershare that I've selected (~6.2TB), but that disk does not show in the available targets. Often, there are zero options for selecting the target. Other times, unBalance offers me target disks that have <1TB free (for this 6+TB transfer) Docker-safe new permissions has been recently run; all dockers are stopped Any idea what's going on here or how to resolve?