NZB Get - Hung While Opening Web Ui


Recommended Posts

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,

Link to comment

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.

Link to comment
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,

Link to comment
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,

Link to comment

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.

Link to comment

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.

  • Like 1
Link to comment
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

Link to comment
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 by codefaux
super.dat demystification
  • Thanks 1
Link to comment
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

Link to comment

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?

 

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.