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.)

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

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?

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?