Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

1 Neutral

About CaryV

  • Rank
  1. 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
  2. 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?
  3. 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.
  4. 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
  5. 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)
  6. 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!
  7. 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
  8. 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
  9. 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...
  10. 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
  11. 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
  12. 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?
  13. 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.