johnny121b

Trying out 6.9.2, and my dashboard is SO unbalanced; left column FULL/TALL, right column....almost empty. Such segregation! TskTskTsk 1 - 2 - 3 1 - 2 1

Title kinda sums it up. System runs fine. 3 dockers (PLEX, NZBGET, SONARR) work fine w/ no delay. Only the HTTP page is SO SLOW it's almost unusable. It can take several minutes to load the dashboard. Saw mention of something similar that was a USB controller issue, but my log file has something different than the other users' incident. Any ideas or pointers would be welcomed. Thanks! Apr 15 03:44:36 tower kernel: mce: [Hardware Error]: Machine check events logged Apr 15 04:03:10 tower kernel: mce: [Hardware Error]: Machine check events logged Apr 15 04:05:42 tower kernel: mce: [Hardware Error]: Machine check events logged Apr 15 04:07:00 tower kernel: mce: [Hardware Error]: Machine check events logged Apr 15 04:07:41 tower kernel: mce: [Hardware Error]: Machine check events logged Apr 15 04:08:01 tower kernel: mce: [Hardware Error]: Machine check events logged Apr 15 04:08:10 tower kernel: mce: [Hardware Error]: Machine check events logged Apr 15 04:09:06 tower kernel: mce_notify_irq: 7 callbacks suppressed Apr 15 04:09:06 tower kernel: mce: [Hardware Error]: Machine check events logged Apr 15 04:09:09 tower kernel: mce: [Hardware Error]: Machine check events logged Apr 15 04:10:10 tower kernel: mce_notify_irq: 9 callbacks suppressed Apr 15 04:10:10 tower kernel: mce: [Hardware Error]: Machine check events logged Apr 15 04:10:13 tower kernel: mce: [Hardware Error]: Machine check events logged Apr 15 06:18:04 tower kernel: docker0: port 1(veth69569df) entered disabled state Apr 15 06:18:04 tower kernel: veth6035b2c: renamed from eth0 Apr 15 06:18:05 tower kernel: docker0: port 1(veth69569df) entered disabled state Apr 15 06:18:05 tower kernel: device veth69569df left promiscuous mode Apr 15 06:18:05 tower kernel: docker0: port 1(veth69569df) entered disabled state Apr 15 06:18:05 tower kernel: docker0: port 1(vethdc9e06c) entered blocking state Apr 15 06:18:05 tower kernel: docker0: port 1(vethdc9e06c) entered disabled state Apr 15 06:18:05 tower kernel: device vethdc9e06c entered promiscuous mode Apr 15 06:18:07 tower kernel: eth0: renamed from veth6a19419 Apr 15 06:18:07 tower kernel: docker0: port 1(vethdc9e06c) entered blocking state Apr 15 06:18:07 tower kernel: docker0: port 1(vethdc9e06c) entered forwarding state Apr 15 06:18:38 tower kernel: docker0: port 1(vethdc9e06c) entered disabled state Apr 15 06:18:38 tower kernel: veth6a19419: renamed from eth0 Apr 15 06:18:39 tower kernel: docker0: port 1(vethdc9e06c) entered disabled state Apr 15 06:18:39 tower kernel: device vethdc9e06c left promiscuous mode Apr 15 06:18:39 tower kernel: docker0: port 1(vethdc9e06c) entered disabled state Apr 15 06:18:39 tower kernel: docker0: port 1(veth74e8edc) entered blocking state Apr 15 06:18:39 tower kernel: docker0: port 1(veth74e8edc) entered disabled state Apr 15 06:18:39 tower kernel: device veth74e8edc entered promiscuous mode Apr 15 06:18:41 tower kernel: eth0: renamed from veth17baf18 Apr 15 06:18:41 tower kernel: docker0: port 1(veth74e8edc) entered blocking state Apr 15 06:18:41 tower kernel: docker0: port 1(veth74e8edc) entered forwarding state Apr 15 12:19:08 tower shfs/user: err: shfs_rmdir: rmdir: /mnt/cache/appdata/binhex-plex/transcode/Transcode/Sessions/plex-transcode-kk8egjzw1vefpv6548wmgrq1-51a8be6c-2de3-46c7-ac56-321946b3c3b9 (39) Directory not empty Apr 15 12:19:08 tower shfs/user: err: shfs_rmdir: rmdir: /mnt/cache/appdata/binhex-plex/transcode/Transcode/Sessions/plex-transcode-kk8egjzw1vefpv6548wmgrq1-51a8be6c-2de3-46c7-ac56-321946b3c3b9 (39) Directory not empty Apr 15 15:25:49 tower emhttp: shcmd (211238): smbcontrol smbd close-share 'TV' Apr 15 15:36:26 tower emhttp: shcmd (211374): smbcontrol smbd close-share 'TV'

I don't have an answer, but have a similar problem. I landed here while searching for an explanation RE: why my HTTP interface has slowed. I'm also seeing loads of 'docker0 port 1 ......entered blocking/forwarding/disabled state' messages in my log. My dockers seem to load/work correctly, but clicking on anything in the http interface- means a wait of about 60-seconds. DASHBOARD -> MAIN = wait 60 seconds......MAIN -> SHARES = wait 60-seconds.....you get the idea. Wondering if you stumbled upon a solution?

The ability to configure shares' schedules such-that, their security settings shift from, say, SECURE <-> PUBLIC during scheduled windows....possibly only for certain users. My use-case; I routinely copy new movie/TV files onto my server from my PC. Each time, I have to manually change my shares' settings from SECURE to PUBLIC to give myself write access.....and revert the setting when I'm finished. The remaining 99% of the time, I want my server to DENY write access to everyone, including myself. I do this to help keep my server safe from any ransomware that might infect any machine on my network. For some operations, I circumvent the need- by copying directly to the cache drive, but for some things, whose directory structure is nested, or when I'm renaming files already ON the array, it's a very manual affair. It would be nice if, for example, my server knew to change my MOVIE share from SECURE to PUBLIC from 10-11pm for user "johnny," and at 11:01pm it reverts back to SECURE. That would allow me to add/delete/rename files each evening but leave it secured otherwise. Thanks!

Go to: SETTINGS | NETWORK | List of IP addresses and networks that are allowed without auth Add the IP addresses you wish to have UNauthenticated access (to work when PLEX servers are down) Example; 192.168.1/255.255.255.0 to allow anything in-house to access regardless of PLEX site condition....if your internal network is 192.168.1.xxx

+1 for the idea. .....even something so basic as the ability to RENAME files in the array, would be helpful. To help protect my server from ransomware, I keep my shares set to prevent even ME from easily changing the files. And I'm not a fan of Midnight Commander, especially with longer filenames.

What's the one thing you WISH you could change about unRAID?

I wonder- Is that first licensee STILL using UnRAID? THAT would be quite the testament!

+1 for the 'intermittently stops while unpacking' issue. For me, this is a longstanding problem- many months. I've gotten into the habit of deleting the download and later telling nzbget to 'download ramaining files' to return it to the queue. Still, it stinks knowing that I MUST check the docker at least once a day, or things will pile up. I REALLY hope something shakes-out on this situation soon, because I know I suck at configuring/understanding dockers. And I KNOW... that if I have to switch to another docker, I'm gonna have a devil of a time making it play nicely with binhex's sonarr. In case any info helps: I'm still running 6.3.5, but I DO keep my dockers up-to-date.

Any plans for adding support for LTO backup? Speaking as a data hoarder, I know my server has grown to a size such-that a catastrophic failure would be almost impossible to recover from, yet 1:1 backup options are limited IF you want LONG TERM storage. Hard drives don't last for decades in cold storage, and I suspect many of us are only one good power surge away from disaster. A UPS and power conditioner transformer only protect you so far.

Neither. I run it on a micro Dell (Inspiron 3050), whose only purpose is to back up my array. I figure- it uses almost no power, it saves me the headache of setting up a VM (which I've not proven very good at doing), doesn't impact my server's performance, plus it gave my 3050 a purpose...I had the thing, but couldn't decide how to use it. I have it physically atop my server, sharing a small, dedicated 5-port switch, so that mountain of data doesn't have to move across my entire network during backups. I start a backup (using remote desktop) then log in periodically.

I'd like to leave my shares set to SECURE 99% of the time, with an easy way to allow myself access on-the-fly to edit filenames, move files, replace files, etc..... but return the system back to a secure state with a click. Ideally, I'd like something as simple as a button I could click, that would open-up write-access on my /movie & /TV shares so I can do what I need to do, then just as easily....click a button and return things to SECURE. -I- am the biggest security risk on my network, but -I- also need to frequently fix filenames and replace files with better copies. A click-ON click-OFF or toggle arrangement, preferably with a timeout feature, that returns to SECURE either after X-minutes or whenever it detects no activity...

Currently, my server is set up with most shares set to 'SECURE'. When I add a movie to my server, I begin the process by launching a batch file that creates the \movie share on my cache drive (if it doesn't already exist), and I copy the movie directly to the cache drive. The movie then gets moved into the array overnight by the mover script. This effectively isolates my array's movie files from ME. I figure IF I were to ever become infected with something nasty, only my cache drive contents could be at-risk. This works well for single-level shares like \movies or \documentaries or \appz..........but it's just not practical for \TV.........which has countless sub-folders. I can't think of a way to handle that share with my current method, short of creating ALL my TV shows' folders on the cache drive every time. That doesn't seem like an elegant want to handle this. Has anyone else found a better way to handle keeping the server secure during the 99% of the time you're NOT manually copying/renaming/moving/interacting with the shares? (That doesn't involve manually toggling the shares' security via http interface every time you need access)

Seems like a big step backwards (producing a kernel that only works with older/smaller drives), but I [am] inclined to believe the issue exists; not between controller <-> drive but between O/S <-> drive.....or between O/S <-> controller. That is, until your reassurance.

I don't believe any incompatibility exists between the controller and my drives. Since last year's attempted update, three of my drives have been upgraded to 8Tb models- without issue. Out of curiosity, is there a specific reason you're still at 6.5.3? I (do) notice that my current 6.3.5 only tells me that 6.5.3 is available for update......wondering why it doesn't say 6.6.7; coincidence or is it some line in the sand, for reasons I'm not aware-of?

I'm running 6.3.5.....mostly because I hit a brick wall w/ a 6.5.3 upgrade attempt last year. Back then, I learned the SAT2-MV8 had compatibility issues with the kernel. IS anyone successfully using the SAT2-MV8 (PCI-X) controllers in their 6.6.x system? Don't wanna go down that rabbit hole again if it's still a hopeless effort. Thanks!

Something's still squirrely. The HTTP interface is unresponsive when I issue the command to take the array down, power down.....or even click the HISTORY button. It just sits there. The "Uptime" counter is continuing to advance, despite the fact it's ignoring the commands. I'd attributed this to the failing drive yesterday, but that drive's disconnected. The entire time I've been typing this, I've had a blank 'Parity/Read-Check History' window atop my system's normal main screen, which I now cannot access. On a whim, I opened another browser and went to my server's IP (just in case Chrome's the real problem), and the IP address never answered. I was able to telnet into the server and issue a reboot command, but the reboot never happens. Going to my server's IPMI screen, I see it's stopped at the same location as I've seen earlier; -the last 3 lines onscreen for reference- Sending all processes the SIGKILL signal. Saving random seed from /dev/urandom in /boot/config/random-seed. Turning off swap. And that's where it will apparently sit until I hit the server's RESET button. (At least that's where it's been for the last 10 minutes.) UPDATE: I tried twice to boot into my normal config and begin a rebuild..never could take the array offline- it hung every time. Restarted into safe mode and started the rebuild. So I'm on a road with no turns for the next 2 days while it writes. I suspect I'll have other issues to address once the rebuild finishes. One fire at a time... Thanks for the response, johnnieblack

Diagnostics attached. tower-diagnostics-20190422-0645.zip

I'm running 6.3.5. Tonight a drive dropped out during a parity check. Unraid stopped the parity check and put a red X by the drive, listing something like 1000 errors. I thought this would be no big deal.....nature's way of telling me which drive needed an upgrade, and I've replaced drives before. Things went South, however, because the GUI wasn't responding. I suspect the system was tied up by the failing drive, but I'm not really sure. (My experience with the WD click-of-death may not be applicable to Unraid). Long-story-short. Did an unclean power-down. Replaced the drive Restarted Drive didn't show "missing" Drive showed "Not installed" This leads me to believe it's NOT going to rebuild the drive if I start the array. If I click the HISTORY button, it tells me the last parity check was cancelled with zero errors. And parity is listed as valid on the main screen. I wanna be very careful how I proceed here. My backup for the data on that drive is a month old, but is likely substantially correct. (I'd recently installed a new/larger drive in the array, so it'd been taking most of the write activity) So, I'm not panicking, but I don't want my ignorance to make things worse. I'd really much rather the system rebuild the drive's contents if at all possible. What's my best/safest course of action?

Your tone implies this is a relatively straighforward step, but the thought of a hiccup leaving me with 700,000+ files to delete, strewn across hundreds of folders....is pretty intimidating. Any suggestions to help ensure this doesn't happen? Or some syntax to leisurely recover, if it does?

I dunno how big the UnRAID market really is, but I doubt L/T is rolling in cash. I figure the user base here can probably make a bigger difference than L/T. I do know Slackware/UnRAID has been a significant part of my hobby life over these last several years. The notion [that he's received nothing directly for the benefits I've enjoyed] didn't seem right...so I wanted to do something beyond just money from one guy. Together, we could make a difference.

I thought some of you might be interested to know- the author of Slackware is in a bad financial situation. It's my understanding Slackware is the basis for UnRAID, one of the oldest maintained Linux distros, and apparently is almost a 1-man-operation. I've supported UnRAID by buying extra licenses in the past, and I think the author of its underpinnings should probably also be worthy of our gratitude as well. I have no connection with him in any way, and if this is inappropriate somehow, I won't be offended if my post is removed, but I think this is worth putting in front of everyone here. Forum discussion that introduced the issue to me. TLDR- see pages 1, 11, 31 (as of this writing) Another mention on distrowatch

I AM probably the biggest risk on my network, but it isn't realistic to expect everyone in my house to live in a bubble. I DO protect my data with backups, but restoring a large system would be a major task- a threat in-and-of-itself. I'm not going to go nuts trying to lock down tablets and laptops, forbid PLEX, cripple my system's usability, and generally quadruple my workload while annoying everyone in the house (including myself), all for a dubious gain. All-the-while, I have a server sitting there, 95% idle, that could be keeping a watchful eye on things, that isn't subject to the latest Windoze update, that isn't having things installed on it daily, that isn't surfing the internet, that has nothing more to do..... I don't begrudge Squid for his choice, but that does not make offloading diligence to an 8-year old or a housewife....a better one. At the moment, this doesn't even affect me. I'm stuck on 6.5.3 because of other issues. I just pursued the point because I wanted to see IF there was something I wasn't aware of....as hinted by one of Squid's comments above.

Mmmmm....yeah. That's not realistic....and not a better solution. Malware is by-definition, proactive. It's no longer enough to be suspicious of Nigerian Prince emails. Bad things can arrive via ads- that you don't even click on, via a webpage or popup....all without user interaction. You can do everything right...and still become a victim. Anyways...really sad to see it fall by the wayside after having its functionality torpedoed by UnRAID's advancement. Thanks for the work you did on it all-the-same.

Can you elaborate on "a more pro-active system"? While I was never a fan of the gigantic number of bait files, I certainly see advantage in relying on a system whose O/S is isolated from the rest of my network. Otherwise, my server's overall safety is determined by the least secure machine (and user) in my house.