CaryV

Has anyone been experiencing a failure with the simple "copy to other panel" function? (or do I need to file a Krusader bug report?) What's happening is this - the copy process appears to "hang", but upon further inspection, the source data has apparently already been copied, but Krusader DOESN'T RESPOND as having finished, FAILING DUE TO ITS OWN STATS! i.e. Displays that it has halted at 77%, having copied 3.6 GiB of 4.6 Gib, WHEN ONLY 3.6 GB actually resides on the source. An inspection of source and target properties shows the same count of files and folders, BUT I have to quit the copy process without it "finishing" according to Krusader itself. Has anyone been having this issue?

Can't find anything about Krusader setup due to BAD* search utility, so What does it take to properly configure Krusader so that it doesn't start in NON-EXISTANT locations? (both panels of Krusader show locations that DON'T EXIST) Krusader is configured to use "last session" and that is CERTAINLY NOT where I left off - as if I could navigate to a non-existant location. BUT, that is how Krusader starts everytime I go to use it (unless it is left running) So, does anyone know how to fix this? *Community search utility doesn't understand basic and/or logic - an attempt to find "last session" or last+session produces either 1000+ hits or 40 pages worth of 'garbage' that has nothing to do with the search criteria. (Looks at individual words, "last", "AND", etc.)

Is anyone still working with v5 and/or plugins? I am dying to run a 32-bit compatible version of unRAID - have PLENTY of hardware to use (dual Athlon and dual Xeon platforms) THAT ARE 32-BIT. BUT, I'm not finding ANY support for the platform. Got an archived version of 5.0.6 - not that it does a lot of good without plugins or apps. Have tried to get a WebGUI and GitHub still lists Bergware/Dynamix 32-bit plugins, NONE of which are available for download; termed "Obsolete". Certainly not obsolete if people are still working on 32-bit platforms... But, UNAVAILABLE? Even found a list of all the v5 plugins "available" (https://wiki.unraid.net/UnRAID5_Plugins) - NONE of which seem to actually be available for download. (Doesn't make much sense if someone went to the trouble of coding it in the first place.) I've found myself pretty much relegated to either running a 32-bit compatible unRAID or having no way to store additional files. Tom had presented the idea at one point of having a "32bit non-PAE version" available for all releases, but I guess that didn't happen... Would be great to run the current software on a 32-bit platform instead of the old v5, but that presents another problem - the need for 32-bit apps that although they have [already] been coded, don't seem to be available. And, I don't even need all the bells and whistles that are currently available for v6 - already have those on a 64-bit platform that is MAXED-OUT. Just need mass storage of files in a secure environment as offered by unRAID, a WebGUI to manage the array, and network access to the files. Can anyone help with this? Thanks

That worked fine, thanks. In fact, all of the SMB shares (from other systems) being utilized on the system with the eSATA share that needed rectified now also appear in Windows - due to all inclusions (in smb-settings.conf) now being referenced. Is there anything that I need to be aware of as to why the smb-extra.conf file didn't get updated?

Resolved the display of "/mnt/disks"; Share still not functional (non-existent across network). Although I had rebooted the system before, this time it was done with "auto-mount" in effect (and of course, "share" is enabled). (No security is in effect; nor has it been used on SMB shares.) This corrected the differences in content displayed in Krusader, however, it did not resolve the sharing dysfunction. B.T.W. Ownership and permissions have been checked and are all normal for the shared device.

Have created a share in UD, but it does not show across the network (neither on another unRAID machine as a SMB share, nor in Windows). Have noticed (in Krusader) that when the device is mounted, everything shows fine in the unassigned directory, but /mnt/disks is not populated (only shows mount point without any directories or contents*)... When attempting to use the share, no 3rd party software is involved. Setting the eSATA drive to "share" does not show the share across the network. (not shown in unassigned devices on other machine in "add SMB share" or in Windows Explorer) (version 2019.12.15) *unassigned directory is a container path, specified to be, "/mnt/disks" that displays the unassigned devices (directly); whereas viewing "/mnt/disks" via "unRAID" and "drilling down" (vs. unassigned path) DOES NOT SHOW CONTENTS (directories, media, etc.) Theoretically, not a possibility, but that is what is being displayed as opposed to every other [working] share where the displays match (when mounted). An inspection of the unRAID log shows that "eSATA" (mount point) has SMB share enabled (but is dysfunctional as described) Diagnostics have been attached. tower-diagnostics-20200407-1631.zip

Have created a share in UD, but it does not show across the network (neither on another unRAID machine as a SMB share, nor in Windows). Have noticed (in Krusader) that when the share is mounted, everything shows fine in the unassigned directory, but /mnt/disks is not populated (only shows mount point without any directories or contents)... NO 3rd party software is involved (only UD). Setting the eSATA drive to "share" does not show any share across the network. (version 2019.12.15)

Good job dgw! I knew I ran across some blurb long ago about how to setup Radarr and Sonarr so that the IP did not have to be respecified for the dowload client(s) each and every time that the (host) system is rebooted... gets REAL tiresome after a while. (AND, I don't quite understand why so many people didn't understand what you were talking about.) Yea, I saw all of SpaceInvaderOne's videos (when I was new to unRaid) – he does a great job of providing pertinent info in a 'condensed' format in order to shortcut the 'learning curve' (to get up and running ASAP); BUT NO, I don't recall that he went over this one. (Or, believe me, I would have done it. Maybe an updated video is in order.) So, in less than a minute, applied your resolve to see. Yep, it works! Just change specification of Network Type from "Bridge" (default) to "Host" in the docker's template and then in Settings for the Download Client(s) replace the "HARD-CODED" IP (that usually changes with every reboot of the system) with "localhost". That combined with the correct Port number (in the next field) and VOILA! Hit "Test" and "successful" communication where it didn't work before (unless the proper, CURRENT IP for unRaid server was input). (Spelled it all out here so that every one can follow what it takes to NEVER HAVE TO CHANGE THE IP ADDRESS AGAIN!) Thanks for providing the answer – this is what the 'community' is all about!

Was a resolve for this ever found? (as posted by allanp81) Nov 24 00:11:28 Headless kernel: XFS (sdh1): metadata I/O error: block 0xeadea1f0 ("xfs_trans_read_buf_map") error 5 numblks 32 Nov 24 00:11:28 Headless kernel: XFS (sdh1): xfs_imap_to_bp: xfs_trans_read_buf() returned error -5. I have the same issue, but it's not just a matter of 'filling' the log file - this occurs with a USB hard drive and when it does, the drive goes 'offline' (unmounted) when it was mounted, shared and usable in unAssigned Devices. AND, it gets better... Not only will it not remount (as is), but if it is disconnected and reattached in hopes of getting it operational - Can't remount the drive because of the following error: Nov 24 00:31:02 Headless kernel: XFS (sdi1): Filesystem has duplicate UUID b53fdadc-8cec-4f92-b699-a4cbc510f52d - can't mount The system seems REALLY "confused" at this point - of course its the same UUID (NOT a duplicate) - IT'S THE SAME DEVICE that was mounted and working and now won't remount (because it is detected as a duplicate?). Can only get it operational again by a reboot of the system, JUST TO HAVE IT HAPPEN AGAIN! (Even tried to change the UUID at this point, but the OS wouldn't have it - says drive's log has to be cleared by mounting the drive, or risk potential 'corruption.) If I can determine what is causing the initial problem that is getting logged, can probably avoid the complications (like the following) Drive goes so far 'out the window' that in addition to the duplicate UUID, also get this: Nov 24 00:31:02 Headless unassigned.devices: Mount of '/dev/sdi1' failed. Error message: mount: /mnt/disks/WCC132184639: wrong fs type, bad option, bad superblock on /dev/sdi1, missing codepage or helper program, or other error. Which CAN'T be correct, otherwise the drive wouldn't have mounted and been usable in the first place. And, if the system is rebooted, the drive CAN be mounted and is once again usable (for however long that lasts, usually not too). Have included diagnostics that shows all of this happening, but have no idea why. Any help would be appreciated. NOTE: It is interesting that the device starts out as "sdh" (the next available designation), but after that it gets a designation of "sdi" EVEN THOUGH THERE IS NO "sdh" and that designation is available; may be the reason the system is 'confused' and issues the duplicate UUID error. headless-diagnostics-20191124-0030.zip

1) Yea, the preclear plug-in is still there; was never a problem before (for months amounting to years), until the USB disk was introduced... and it didn't come into play UNTIL the USB drive went 'offline' (became unmounted). If need be, I can remove it for trouble-shooting purposes, but I'm not sure that addresses the issue which will be made clear by what I've perceived to be the sequence of events that triggers the problem... if the issue can be reproduced, maybe there is a way to resolve. 2) NO Jumbo Frames are in use, just MTU (standard, default) 3) Am using a Windows machine to monitor / administer the two unRaid systems; use of NFS may not be an option in this case. So, as to being able to reproduce the situation which triggers the hanging of UD, this is what appears to transpire. I attempt to get the USB drive back online by manipulating the 'source' system and while I mentioned that I "unmounted" the SMB share on the 'object' system for the USB drive (when it went 'offline' again), I still had two other SMB shares specified as active (mounted); one to the disk array of the 'source' system; specifically the media content thereof so as to be able to maintain a 'master catalog' on the object system, and another SMB share for a SSD drive so as to include its contents in searches I conduct. The reason that I mention these connections is because they may well have an impact on the situation, although it did not arise until the introduction of the USB drive, so, to continue. I was able to view unAssigned devices on the 'object' system AFTER the USB drive went 'offline', hence the statement that I "unmounted" it on the 'object' system (the system where UD hangs vs. the 'source' system where the USB drive is physically attached). unAssigned Devices did not hang until after I attempted to remount the USB drive (as indicated by the error message that follows) AND subsequently disabled those device(s) on the 'source' system that were being shared and specified as SMB shares (in UD) on the 'object' system. "Nov 22 00:49:04 Headless unassigned.devices: Mount of '/dev/sdi1' failed. Error message: mount: /mnt/disks/WCC132184639: wrong fs type, bad option, bad superblock on /dev/sdi1, missing codepage or helper program, or other error." This error does not occur initially; it only appears after the disk had been successfully mounted and in use (for hours) and then goes 'offline'. We can also now see why it went offline, or more precisely why it was TAKEN offline; as in "Nov 22 00:49:04 Headless kernel: XFS (sdi1): Filesystem has duplicate UUID a2e64706-14cd-44b6-b7b2-e1ec18f0e97e - can't mount" As I stated in the notation in the log file (uploaded) this is not exactly true... The drive WAS mounted to begin with; if it was actually (physically) in a system where there was a UUID conflict, it would not have mounted in the first place. It is a duplicate UUID only across the network - as to why the OS objects to that, I have no idea; it attempts to extend that uniqueness to other machines and although that is an easy resolve in order to keep it from going offline, it begs the question as to why UD hangs... which is The termination of the 'sources' of the SMB shares, or more appropriately, the resources being shared, as in 'stopping' them on the 'source' machine triggers the hang with UD on the 'object' machine. This is what I witnessed when I 'manipulated' the 'source' machine in an attempt to get the USB drive back online (mounted). Stopping the disk array on that machine disconnects or disassociates the resources with the SMB connection on the 'object' machine. Disconnects certainly. Disassociates in that once the array is brought back online, it does not re-establish the (SMB) connection on the 'object' machine; nor could it as UD hung at the point of the disconnection. (Which is why the following message appeared in the log file; the designation was no longer valid) "Nov 22 00:10:19 Tower kernel: CIFS VFS: BAD_NETWORK_NAME: \\HEADLESS\OCZ-AGILITY3" Does this make sense as I've presented it? Where does that leave us? Right now, I have a machine with UD hung that I can't stop, shutdown, or reboot (without "pulling the plug"). Anything you want me to try before I do so (and face the impact of an unclean shutdown)? (All of the 'other' operations that were active before, downloads and parity checking, have concluded at this point.) Cary

Johnnie, Thanks for that; may need to know this one to change the UUID without resorting to a reformat of drive... What's interesting is that the drive is NOT in the same system. It's physically attached to a different system and being utilized by a SMB share setup through unAssigned Devices. (The drive is a shared unAssigned device on another system; other than the one where a drive 'took its place' that DOES have the same UUID.) I'm not sure why the OS has a problem with this...

Didn't think I'd run across this again, at least not so soon (but I did) and here are the log files from both of the unRaid systems involved; "headless" file is from the 'source' system that has the USB drive physically attached - the one that went 'offline' (again) and precipitates the problem. "Tower" file is from the 'object' system that uses a SMB share to access the USB drive (and other SMB shares from the 'source' system). Tower is the system that has unAssigned Devices hanging - which it is again. I have to leave the system running in this condition until other operations complete, then I can try whatever you suggest to remedy the situation. (We already know that in the alternative, I'll have to "pull the plug" on the system.) I have added highlighting to pertinent portions of the logs as well as some operational notes that may be of benefit. Thanks, Cary unAssigned_Hang (3) log_headless.rtf unAssigned_Hang (4) log_tower.rtf

dlandon, In an effort to try to 'pin down' the issue, here is the precise sequence of events: Was working in Krusader with the unAssigned device through a SMB share (and with a local drive in the unRaid array that should have had the "same" contents, rebuilt). The 'contents' of the unAssigned device "disappeared" (in Krusader) Used 'telnet' to look at the drive (USB) attached to the 'source' system - directory system of the drive was prefaced with a number of ??????? and any attempt to navigate within that system was met with an I/O error (Yes, it truly was offline - went South for no discernable reason, having been used in its configuration for a number of hours without issue.) Reason for this is a matter of conjecture, based on what occurred subsequently, but believe it was due to operation of unRaid (on its own, without user action), whereby it was taken 'offline'. (see indication* below) Attempting to look at the SMB device in unAttached Devices (Main page of unRaid) only showed the 'continuous wavy line' displayed that never resolved in order to show the unAssigned devices - which would be 4 SMB mounted devices; two to the 'source' system's unRaid array (one of which had been mounted), one to a SSD (unAssigned device on the 'source' system, and one to the USB attached hard-drive, once again, attached to the 'source' system as an unAssigned device and utilized through a SMB share on the 'object' system. (Source system = secondary unRaid server with an array (of four drives), a SSD (unAssigned and shared), and a USB hard drive (unAssigned and shared; the device in question) An inspection of the 'source' system showed that, yes indeed, the USB hard drive had gone 'offline' and was no longer "mounted" (although the drive itself was not an issue and was still running; the indication* was that the drive had been taken 'offline' by unRaid). This indication came about when it was attempted to bring the drive back online in order to resolve the issue at the 'object' system (issue of unAssigned Devices not responding on the 'object' system): Selected "mount" of the drive which failed. Stopped all Dockers as well as the unRaid array - it was at that time that the "indication" appeared as at the bottom of the 'page'; an admonishment that there were "too many" (mass storage) devices attached (for current licensing); although, according to unRaid specs, the USB hard-drive should NOT have been counted... Nonetheless, as the USB drive would not mount (remount) whether the Dockers were stopped, array was stopped, or drive itself was powered off and on, it was time to reboot (source system). Note: Interestingly enough, unRaid displayed a notification of the drive's condition (errors from SMART; reallocated sectors and reported uncorrect) upon its being power cycled, yet, would still not mount the drive. After rebooting and restarting the unRaid array as well as the Dockers (apps), reattached the USB drive, mounted and shared - all running as before; however unAssigned Devices on the 'object' system was still "hung". That's when the unRaid array was attempted to be 'stopped', but did not respond; nor was it possible (many minutes later) to Power down or to Reboot the system (softly). Subsequently, depressed the power switch (briefly) which showed that the system was attempting shutdown with its "waiting 90 seconds" for a clean shutdown that never happened. Hung big-time and had to perform a cold reboot. And, that's the best that I can tell you. Hope it is of benefit in finding a resolution. The indication is that the event was triggered by unRaid when the drive went 'offline' and that unAssigned Devices suffered from the event in the environment in which it was operating. I understand what you said about the device attachments and the way communication takes place using the SMB shares; as well as the fact the calls are made to OS commands. Commands of which you have no control in their operation... Best bet seems to be to have unAssigned devices attempt to circumvent the issue when a device being utilized in unAttached Devices goes offline, so that the 'offending' call is not made in relation to the utilized resource (unAttached device, SMB share). (Sounds like this has attempted to be done through the limit on 'df' calls and use of time-outs.) As far as diagnostics are concerned, I presume those would have to be (have been) collected at the time of occurrence. You are speaking of unRaid diagnostics, correct? My understanding is that once an unRaid system is rebooted (which both have been at this time), the diagnostics of the condition(s) in question are lost. Anything else that I can do to provide information, let me know. Cary

Mustava asked a VERY valid question that was never responded to... What does it take to either Restart or Terminate unAssigned Devices? (This plug-in can HANG the system!) As if that isn't bad enough, the end result is a COLD REBOOT with resultant unclean shutdown and a parity check (for HOURS) upon restarting. CANNOT Stop the unRaid array or use Shutdown or Reboot - TOTALLY UNRESPONSIVE DUE TO UNASSIGNED DEVICES BEING HUNG! (Indicated by the 'wavy lines' running perpetually in the "unAssigned Devices section without ever resolving - EVERYTHING else still works; unRaid, Dockers, etc. Just NO unAssigned Devices) Scenario starts when one of the unAssigned Devices has an issue; i.e. Had a USB drive connected and shared on secondary system. It stopped running (for whatever reason) and the SMB share to it from the 'primary' system stopped being operational, CAUSING unAssigned Devices to HANG (revealed upon navigating to the unRaid Main page to inspect the device, but unAssigned Devices would no longer respond) AND as mentioned, could not stop the array, reboot, or shutdown the system. Not without have to "pull the plug" altogether... NOT A GOOD SCENARIO. So, what does it take to terminate or restart the program (similar to restarting a Docker app) OR avoid unAssigned Devices from hanging in the first place?

Well that's nice... So where is the UD thread?

To Bonienl, I'll be aware of the in the future.

Cool, Johnnie.Black. Thanks for the info; that would explain the conflict. Would have to do some research about 'wiping' it (if the drive would then be usable) or replacing it otherwise. In the meantime, I got the drive to work on the 'secondary' unRaid system v6.5.3 where its operation wasn't "conflicted", but certainly "flakey". Noticed that even though the drive was "shared", the mount point WAS NOT! Sometimes (not always) it had to be set to "share" individually and EVEN THEN it did not always appear across the network. Once it did, I was able to us a SMB share to access it from its system of origin and compare its contents to that of the 'rebuilt' drive that replaced it. BIG JOB! (Unless someone knows of a better, faster way) I'm using Krusader to generate checksum file(s) and then doing a binary compare on the checksum files between the two disks. It works, but slow going - felt it had to be done before I 'repurpose' the drive because of the 163 (undefined) errors from the rebuild... that's all that was presented, save for the CRC error, in which case I know the bit(s) weren't read properly, so some file(s) got 'hosed' in the rebuild operation. Not that I don't trust computers. I trust them to be a continual source of "entertainment" in which I don't believe it until I see it... Including operation(s) in unRaid and associated apps. BTW on the machine to which the "old" drive is now 'mated', (binhex-) Krusader v2.7.1 STILL DOES NOT SHOW THE CONTENTS, yet they can be seen in telnet, by the SMB share, and on the "console" (Windows) machine used to control the two (headless) unRaid servers... see what I mean about not believing it until I see it? At any rate, thanks for the info. I like to spell-out what I find for the benefit of others facing similar situations; if I can 'find' such problems, I'm sure someone else has probably run across them too.

First off, because it is here, Secondly, because it was the only pertinent thread found, and yes, I'm running version 6 and it is STILL a problem...

Have a similar problem, but I DO NOT want to add the drive to the unRaid array - it WAS a member of that array, but developed so many bad (reallocated) sectors that it was replaced and "rebuilt". Problem is the "rebuild" completed with 163 (unidentifed) errors, including an 'unrecovered' CRC error between the parity drive and drive#6. (It was drive#3 that was replaced in the array.) Therefore, the contents of the "new" drive are in question and the contents of the "old" drive are intact... Ideally, I wish to mount the "old" drive on either the same machine as an unAssigned device WITH the Array running, or on another machine and using a SMB share, compare the contents of the 'old' drive vs. the rebuilt 'new' drive; however, THIS remains to be accomplished... As Bitbass encounted, the "old" drive will not mount WITH the array running. Same here, EXCEPT, I could bring-up the array subsequently. BUT, the "new" drive was missing from the configuration as "unmountable" because of "no file system". That condition was recoverered from AS SOON AS the "old" drive was not mounted along with the Array running - THERE IS AN APPARENT CONFLICT between the two drives; the "old" #3 from the array and the "new" #3, SO The problem remains with having access to the "old" drive and the "new" drive AT THE SAME TIME, in order to inspect the contents. Additionally, as I have another unRaid machine, I attempted to mount it there in unAssigned devices and could do so with its array running, BUT when the "mount point" was accessed, it showed NO CONTENTS, when the contents had been verified when it was mounted on the first machine. On top to that, I installed "Linux file system for Windows" on a Windows machine - SAME ISSUE - will mount, but contents of the mount point folder are "empty". Now, I really am stuck on how to access the data on that drive. Any ideas, gentlemen? (If the conflict between the two drives could be resolved, that would probably provide the quickest means of accomplishing the task. What needs to be 'altered' on the "old" drive in this case?)

gfjardim may well be correct as to why unRAID did not detect the precleared condition. As far as preclear functioning, I'm sure he would know, and most certainly in this case the disk WAS formatted in Unassigned Devices BEFORE adding it to the array... guess that takes the onus off of unRAID if the signature gets 'wiped' upon formatting and the precleared condition could not be recognized. I imagine this should be documented somewhere, but I've never seen it. Followed the procedure of a YouTube video on adding a disk to an array. The "little detail" on adding the disk to the array BEFORE formatting was omitted in the video (just stated that it had to be formatted before it could be mounted). Would be a procedural issue in this case that one needs to be aware of... thank-you for the input and the response.

Without a doubt, something is "broken" in the new release of unAssigned Devices as of 2019.03.28 Reverted unassigned.device.plg and unassigned.devices directory contents to the 2019.02.12 version (from my manual backup). Verified by checking plug-ins and upon a reboot with the "old" version reinstalled (reboot had been done with the "new" version, to no avail) SMB share now mounts. New rev needs to be taken a look at. Is there any information from my system that you need? (I did look at logs for unAssigned Devices, but nothing was there and from what I read it is used for logging scripting errors.)

HELP! SMB shares NO LONGER MOUNT as of the last Unassigned Devices update (3/28/2019). SMB shares have existed and been working since their inception (many moons ago) and have continued to work through a number of updates UNTIL NOW. Absolutely an issue with Unassigned Devices as unRaid version was unchanged, the application that uses (used) the SMB share (and is now dysfunctional) did not change, NOR were any configuration changes made... ONLY update of Unassigned Devices. Have "re-added" the share which still comes-up (from another unRaid server). Finds server, share is selected, BUT IT WILL NOT MOUNT; FAILS EVERYTIME. Even changed Settings to force SMB v1 just in case; MAKES NO DIFFERENCE. Unassigned Devices NO LONGER FUNCTIONS WITH SMB SHARES. What does it take to fix the problem?

I have gone over the same rhetoric a number of time when it comes to disk utilization as to what it does and what it does not do, ad nauseam, simply because IT DOES NOT OPERATE THE WAY THAT IT SHOULD so everyone tries to figure out just what it is doing... If it would operate in a USEFUL manner, there would not be a problem, BUT IT DOES NOT. And, here is why - in this, I'm in complete agreement with the guy who first wrote as to what "minimum" SHOULD mean. The idea is to "fill-up" the disk up to a "minimum" so as to allow for some remaining free space AS SPECIFIED BY THE MINIMUM. Once the minimum has been reached (or exceeded in order to finish a file write), move to the next disk that has space available above the MINIMUM. With an adequate "minimum" there should be no issue with failed writes of a file and their associated files or metadata. (Without an adequate minimum, writing of a file or file folder with contents SHOULD STILL CONTINUE to the next disk, unless dis-allowed by the split-level*.) To use it to specify the "minimum" that needs to be available AS A MINIMUM ABOVE the size of the file to be written IS USELESS! If you wish to write a file to the disk (automated or otherwise) THEN YOU WANT THE FILE TO BE WRITTEN! And who gives a shit about it's size, as long as there is sufficient disk space and the minimum has not (yet) been reached. The likelihood of a write failure due to running out of space on a disk in this manner (with a proper "minimum") is just about negligible AS COMPARED TO UTILIZING A "MINIMUM" IN THE MANNER SPECIFIED HERE! Therefore, it should be coded to be used in a manner as WOULD BE ASSUMED BY ITS VERY NAME. To do otherwise is pretty damned USELESS and CREATES PROBLEMS... (as exemplified by the INNUMERABLE times this issue is raised) So, why does it not operate in a manner where IT WOULD BE OF USE (LimeTech)? *I also understand why the split-level is then increased by users who are attempting to utilize their disks in such a manner in order to allow use of the next disk when a disk "fills-up". (Which wouldn't have happened with the PROPER APPLICATION OF A MINIMUM SPECIFICATION.) This "split-level" then creates a problem when the split does not coincide with the "logical" desire to keep ASSOCIATED FILES on the same disk. i.e. Due to disk utilization issues CREATED by the "minimum" not operating in a USEFUL manner, the split-level has to be increased so the writes occur to the next disk which has space. What occurs then is that despite it being specified in the application (and desired) to keep associated files in the same folder as the media (movie, TV episode, song, or album, etc.), the ASSOCIATED METADATA ends-up on another disk altogether (in a folder of the same name)... NOT WHAT IS DESIRED AT ALL – AND IT ALL STARTS WITH NOT BEING ABLE TO SPECIFY THE MINIMUM DISK SPACE (reserved) TO BEGIN WITH!

YEA, SOMEBODY MISSED THE BOAT!!! (And the instructions on replacing the cache drive need some revision.) I got the same "blank" Docker with no containers after changing the cache disk Per Instructions... because it is 'rebuilt' upon re-enabling Docker in settings. However, after my last 'fiasco' of a Plex update 'screwing the pooch' and finding that CA Backup WON'T RESTORE TO A KNOWN GOOD CONDITION (as of the backup made BEFORE the update), I don't take anything for granted - including, making a (manual) backup of the docker.img file. So, here is the proper procedure to be "up and running" without finding Docker with no containers and having to reinstall, re-download, reconfigure, whatever. BEFORE re-enabling Docker in the Settings (after cache disk replacement) - copy the (manual) backup of your docker.img file that came from the old cache drive (made BEFORE its removal) to the new cache disk (from where ever you placed it on the array to the /mnt/cache/system/docker directory), THEN re-enable Docker. Everything will be as you left it, all functional (from what I witnessed), without having to spend any (unnecessary) additional time. BTW - Ignore the message that "existing Docker image needs to be recreated due to an issue from an earlier beta of unRAID 6". We know it's not true, but it's nice that unRAID detected the use of an existing file instead of a (an empty) rebuild.