Jonas_Venture Posted April 22, 2021 Share Posted April 22, 2021 I am having an issue where nzbget is getting hung on the loading page, it eventually times out and says there is a communication error. I currently am using binhex-nzbget, but I also downloaded and tried the linux server nzbget and I am having the same issue. I also have deleted the docker image, reinstalled, and rebooted multiple times with no change. Any help would be appreciated. Thanks, Quote Link to comment
ChatNoir Posted April 23, 2021 Share Posted April 23, 2021 You should probably seek help on the support page of the app. You can access it easily from the popup menu of the Docker tab : "? Support" Quote Link to comment
6of6 Posted April 23, 2021 Share Posted April 23, 2021 Or... Make sure its nzbget and not the UnRAID WebUI by accessing nzbget by its <ip>:port address outside the UnRAID WebUI. You didn't say how you were accessing the nzbget WebUI, so I'm sorry if I suggested something you were already doing/trying. 6. Quote Link to comment
Jonas_Venture Posted April 23, 2021 Author Share Posted April 23, 2021 9 hours ago, ChatNoir said: You should probably seek help on the support page of the app. You can access it easily from the popup menu of the Docker tab : "? Support" Hi, I did post there earlier this week with no response so I thought I would try here. Let me know if it is not the right place and I can delete this post. Thanks, Quote Link to comment
Jonas_Venture Posted April 23, 2021 Author Share Posted April 23, 2021 9 hours ago, 6of6 said: Or... Make sure its nzbget and not the UnRAID WebUI by accessing nzbget by its <ip>:port address outside the UnRAID WebUI. You didn't say how you were accessing the nzbget WebUI, so I'm sorry if I suggested something you were already doing/trying. 6. Hi, Thanks, I did try that. Appreciate the suggestion. Cheers, Quote Link to comment
6of6 Posted April 29, 2021 Share Posted April 29, 2021 Completely unrelated... I started using SABnzb only because NZBget wouldn't work. I say, "completely unrelated" because it was on my Windoze box a few years ago. If one doesn't work, try the other. (disclaimer: I have no affiliation whatsoever to either.) 6. Quote Link to comment
codefaux Posted April 29, 2021 Share Posted April 29, 2021 First thing to confirm is that your system is as stable as it seems. As a longtimer, it can seem fine and have subtle issues. If you're still interested in making sure things are good, it's best to start with a diagnostic.zip file. It's generally the first thing you'll get pinged for here, and it's typically a good starting point. Important things we're looking at are kernel logs and docker logs, both of which are going to be invaluable in tracing issues. That'll be on Tools, Diagnostics, Download. Drag and drop that onto your next reply, and someone (I WILL eventually respond if you reply and the forum delivers the notification properly, but it might not be immediate) will look into it a little more. 1 Quote Link to comment
awediohead Posted April 29, 2021 Share Posted April 29, 2021 23 minutes ago, codefaux said: First thing to confirm is that your system is as stable as it seems. As a longtimer, it can seem fine and have subtle issues. If you're still interested in making sure things are good, it's best to start with a diagnostic.zip file. It's generally the first thing you'll get pinged for here, and it's typically a good starting point. Important things we're looking at are kernel logs and docker logs, both of which are going to be invaluable in tracing issues. That'll be on Tools, Diagnostics, Download. Drag and drop that onto your next reply, and someone (I WILL eventually respond if you reply and the forum delivers the notification properly, but it might not be immediate) will look into it a little more. Just for future reference in supplying the forum with a diagnostic.zip file are there any recommended edits that should be made before uploading to preserve privacy? thanks Quote Link to comment
codefaux Posted April 29, 2021 Share Posted April 29, 2021 (edited) 15 hours ago, awediohead said: Just for future reference in supplying the forum with a diagnostic.zip file are there any recommended edits that should be made before uploading to preserve privacy? Fantastic question. Here's a breakdown, but it's mostly human-readable and broken into easily named, sorted files -- it's not for machine processing, it's for the support staff to parse by hand. What we can see that Could Matter(tm) regarding privacy explicitly: * AS OF UNRAID 6.8.3 (NOTE - I'm scanning my own diagnostic live, YMMV and I might miss something, I'd advise skimming it yourself just so you know for sure.) Config: - Where you keep your encryption keyfile, but not the file or what's in it, if you're using one. Not many people use them, you know if you have it. - Machine name, network domain name, timezone, machine's IP configuration - Folder names specifically of storage locations for docker/VM configuration data - where you're sending syslogs, if you are - Whatever super.dat is, it's 4kb and seems to have a structure containing the names your disk controller assigns to your disks, and other data. (Confirmed by trurl below. If I understand correctly at this juncture, it's an internal file containing, essentially, your disk assignments, in a format prepared for part of the parity system, to over-simplify it) Logs: - Docker logs: Possible these could contain privacy-violating information, depending on your definition of privacy-violating, your containers, how they're configured, etc etc -- in general the worst thing here is someone might see a password that a container is repeating plaintext, which is kind of frowned on to begin with so you should be safe. Shares: - Non-system shares' filenames are masked and internal contents are fairly privacy-safe. NFS shares can expose the name of the share accidentally. Other: - Important folders in a few places have diagnostic file listings. If you try to hide extra things there, we can see their names and file properties. -- /boot, /boot/config, /boot/config/plugins, /boot/extra, /boot/syslinux, /var/log, /var/log/plugins, /var/log/packages, /tmp - Again, internal IP configuration. TECHNICALLY, using IP configuration an attacker can gain a better understanding of your internal infrastructure etc etc but honestly if you're running unRAID and not some blackbox OS you're not really enough of a target that this information is likely to be damaging, valuable, or identifying in any way. - Attached devices, including USB, but not what's on them with the exception of the formerly mentioned folders. - Hardware information, but come on -- it's computer support. - Running processes, including parameters passed to them. -- WHAT! WHY!? It contains the output of, seemingly, ps aux -- a Linux tool, asked to list all information about running processes. Generally this isn't considered leaky, but it exposes hard-coded command-line-passed usernames, passwords, folders, etc involved with running processes. A media server might show ffmpeg processes and the names of media being played, transcoded, etc. A running unpack might leak the name of a pirated download. Generally, if you're paranoid, stop services and containers involved with things you'd prefer unseen before capturing the diagnostic. Also generally? We don't really care that much. We're mostly here to help, but we do respect your privacy. If you're more paranoid than that, and consider the leaks I've mentioned to be too significant, you might ask your volunteer support members very nicely to specify which elements they would most like to see, and consider the implications. Edited April 30, 2021 by codefaux super.dat demystification 1 Quote Link to comment
trurl Posted April 30, 2021 Share Posted April 30, 2021 13 hours ago, codefaux said: Whatever super.dat is It IS your disk assignments. Without that file Unraid doesn't know which disk is assigned to which slot. 1 Quote Link to comment
codefaux Posted April 30, 2021 Share Posted April 30, 2021 17 minutes ago, trurl said: disk assignments Awesome - I saw it earlier today referenced in an internal md-related command, so I figured it was either that or a sort of superblock cache. Thanks for clearing it up. Quote Link to comment
Jonas_Venture Posted April 30, 2021 Author Share Posted April 30, 2021 On 4/29/2021 at 3:44 AM, codefaux said: First thing to confirm is that your system is as stable as it seems. As a longtimer, it can seem fine and have subtle issues. If you're still interested in making sure things are good, it's best to start with a diagnostic.zip file. It's generally the first thing you'll get pinged for here, and it's typically a good starting point. Important things we're looking at are kernel logs and docker logs, both of which are going to be invaluable in tracing issues. That'll be on Tools, Diagnostics, Download. Drag and drop that onto your next reply, and someone (I WILL eventually respond if you reply and the forum delivers the notification properly, but it might not be immediate) will look into it a little more. Hi, Thanks for the input, I have attached the diagnostics.zip, hopefully it sheds some light on the issue. Appreciate it. tower-diagnostics-20210430-1047.zip Quote Link to comment
codefaux Posted April 30, 2021 Share Posted April 30, 2021 Alrighty - good news, your log doesn't show any stability concerns and everything looks healthy. Unrelated, but I would like to address -- three of your WD Red disks are SMR. This is not...inherently bad, but they have some big caveats, and you'll want to make sure -- at minimum -- that the SMR disks do not run your Parity or Cache at any time in the future, as those are roles they would bottleneck. Here's some information in case you don't know; https://blog.macrium.com/macriums-view-on-the-recent-smr-disk-controversy-778ae03b19f8 Next, you said you've deleted the containers several times, so it sounds like there's nothing there you "need" - correct? It might be wise to also delete their data folders from appdata on unRAID, through whichever means you prefer, and try again. Deleting a container does not delete data from its volumes, which live by default in the appdata directory. It could simply have corrupted a database or settings file, and need recreation. Once you've set up and started the container, you can view the container's logs on the Docker page. As of unRAID 6.8.3 the log viewer is far right, I believe with 6.9.x it moved to clicking the container's icon on the left. These provide some feedback as to problems as well, so if you haven't been there yet, take a look. If you don't know how to interpret it, share it here. Regarding the containers, I'm running the Linuxserver version right now, so if you want, give the above a try with the linuxserver version, and if it doesn't work come back and answer some questions. - I assume you've also used the Community Applications plugin to acquire it, correct? - Did you assign the PUID and GID properly? - What Network Type are you using? - Whick URL did you use to connect to it with your web browser? Quote Link to comment
trurl Posted April 30, 2021 Share Posted April 30, 2021 Another thing that can be useful when you are having problems with a docker container is posting your docker run command as explained in the very first link in the Docker FAQ: 1 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.