Errors & Troubleshooting

What the error actually means and what fixes it. This section covers NNTP response codes like 430, 480, and 502, along with repair failures, stalled downloads, connection problems, and unpacking errors. Each entry separates causes that sit with the provider from causes that sit with the indexer or the local machine, because that distinction determines the fix.

41 terms in this category.

430 No Such Article: A response code returned when the requested article is not present in the server's spool. On binary groups it usually means the post aged out past retention, never propagated to that server, or was removed from the spool. Scattered 430s across a few segments are normal and posted PAR2 blocks cover them, but 430s on every segment of a file set mean the release is not carried there at all.
480 Authentication Required: Returned when a client issues a command before identifying itself, telling it to send AUTHINFO USER and AUTHINFO PASS first. Most often the newsreader has no username and password saved for that server, or the credential fields were left blank after a settings import. A 480 says nothing about whether the login is valid; that verdict arrives afterwards as either an acceptance or a 481.
481 Authentication Failed: Sent after an AUTHINFO exchange when the server rejects the credentials supplied. Usual causes are a mistyped password, an email address entered where the provider issues a separate username, or an account that has expired or been suspended. Some servers also report an exceeded connection allowance as 481 rather than 502, so a login that worked an hour earlier and fails now points at connection count instead.
400 Service Discontinued: Sent as the server closes a connection, either because an idle session passed its timeout or because the daemon is shutting down for maintenance. Newsreaders reconnect on their own and the transfer resumes, so an occasional 400 in a log is harmless. A 400 arriving seconds after every connect points instead at the provider or at network equipment dropping sessions, not at client configuration.
411 No Such Newsgroup: The reply to a GROUP command naming a group the server does not carry, or a group name containing a typo. Providers differ in which hierarchies they accept, and many drop defunct groups or ones that carry nothing but spam. Comparing the name against the server's own group list settles which of the two applies. Clients importing a group list from another provider hit this most.
423 No Such Article Number: Returned to an ARTICLE, HEAD, or BODY command naming an article number outside the range currently held for that group. The number either expired out of the spool or never existed, since numbering is per server and gaps are ordinary. Clients working from a cached header index cause most of these, and refreshing headers for the group realigns local numbering with what the server actually holds.
500 Command Not Recognized: The response when a server does not implement the command it received, or the command arrived malformed. Older servers reject compressed-header and streaming extensions this way, so a client that assumes modern features logs 500s during session setup. Harmless as long as the client falls back to plain XOVER. Issuing CAPABILITIES at the start of a session shows which commands that server actually supports.
502 Access Restricted: Returned when the server refuses the session outright. On commercial providers this most often means the account already holds its maximum number of connections, or the subscription lapsed, rather than a bad password. It also appears when an IP-authenticated account connects from an unregistered address. Lowering the connection count in the client, or checking the account expiry date, clears nearly all of them.
503 Timeout: Signals an internal fault or a timeout on the server while handling a request, meaning the command failed on the far end rather than in the client. Isolated 503s under heavy load are unremarkable and a retry normally succeeds. A steady run of them from one server, while a second provider serves the same NZB cleanly, identifies which side of the connection is at fault.
Connection Refused: A failure at the TCP layer, before any NNTP conversation begins: nothing is listening at the address and port the client dialed. Common causes are a wrong port number in the server settings, port 119 blocked by an ISP or local firewall, and a hostname pointing at a decommissioned machine. Trying the encrypted port 563 separates a blocked plaintext port from a genuinely unreachable host.
Connection Reset: An established session torn down mid-transfer by one side sending a TCP reset. Sources include an overloaded server shedding surplus connections, a home router with an exhausted NAT table, and network equipment interfering with plaintext traffic. Reducing the connection count and moving to encrypted port 563 clears most cases. Newsreaders retry affected segments automatically, so occasional resets surface only as retries in the log.
SSL Handshake Failure: Occurs when client and server cannot agree on an encrypted session, so no NNTP command is ever exchanged. Typical causes are an old newsreader offering only deprecated TLS versions or ciphers, a system clock wrong enough to invalidate the certificate window, and SSL enabled against a plaintext port. Updating the client, correcting the clock, and confirming 563 rather than 119 covers almost every instance.
Certificate Error: Raised when the certificate a news server presents fails validation: the name does not match the hostname configured, the certificate has expired, or it was signed by an authority the client does not trust. A wrong system date produces the identical warning against a perfectly valid certificate. Turning verification off hides the message and removes the protection, so fixing the hostname or the clock is the real remedy.
Incomplete Article: An article that arrives truncated, or a multipart binary whose decoded output falls short of the size its yEnc header declared. The cause is almost always a segment that expired or never reached that server, not corruption in transit. Clients mark the file incomplete and hand it to PAR2 repair; if the posted recovery blocks cover the shortfall the file rebuilds, and otherwise a second provider is needed.
Missing Segment: A part of a multi-article binary that a server cannot supply, reported to the client as a 430. Large releases are split into thousands of segments, so a handful absent is routine and the posted PAR2 blocks absorb it. Segments missing across every file in a set indicate a release the provider never received or has since removed, which no amount of repair will recover.
Article Not Found: The general condition behind both 430 and 423 responses: the article requested is not in that server's spool. Age past the retention window is the most frequent reason, followed by incomplete propagation and removal from the spool. Because spools differ between backbones, an article absent from one provider is often present on another, which is why multi-server setups raise completion on older releases.
Repair Failed: The outcome when PAR2 verification finds more missing or damaged data than the recovery blocks in the set can reconstruct. Fetching the release's remaining .par2 volumes sometimes supplies enough blocks; more often the shortfall is too large and the absent segments must come from a server on a different backbone. Repair also fails when the disk runs out of space mid-check, which looks much the same in logs.
Insufficient PAR Blocks: The specific repair failure where missing blocks outnumber the recovery blocks posted with a release. A set posted with ten percent parity survives roughly ten percent loss and no more. Downloading additional .par2 volumes helps only when the poster uploaded them and they still exist. Otherwise the remedy is a second provider on an independent backbone that holds the segments the first one lacks.
Unpack Failed: Raised when the extraction step cannot open or complete a RAR or 7z set after download. The causes divide cleanly: a missing or damaged volume means the download or repair stage left bad data, a password prompt means the archive is encrypted, and a write error means the destination disk is full or permissions are wrong. Running PAR2 verification first shows which of the three applies.
Password Required: The prompt an extraction tool raises when a RAR or 7z archive is encrypted and no passphrase was supplied. The password is commonly placed in the release's .nfo file, in NZB metadata, or on the indexer page the NZB came from. Nothing here is a server or download fault: the segments arrived intact and only the local unpacking step is blocked.
Wrong Password: Covers two unrelated failures that read alike in logs. On a news server it is a rejected AUTHINFO exchange, returned as 481, usually a mistyped login or an account past its expiry date. On an encrypted archive it is a passphrase that does not match, halting extraction after a complete and healthy download. Noting which stage logged the message separates a provider problem from a local one.
Stalled Download: A queue that stops advancing while connections stay open, usually because the remaining segments all return 430 and the client keeps retrying instead of failing the file. Other causes are a full destination volume, a post-processing script waiting on something, and an oversized retry setting. Checking whether any connection is still moving bytes separates a dead release from a client stuck on its own logic.
Slow Download: Throughput well below the line rate, most often caused by too few connections rather than by the provider. Encrypted transfers on low-power hardware can exhaust the processor before the network fills, and unpacking or repair competes for the same disk the download writes to. Raising the connection count, testing briefly without SSL, and watching disk activity during unpack isolate which of the three is responsible.
Connection Limit Reached: The state where an account already holds the maximum simultaneous connections its plan allows, so further attempts are refused, typically with a 502 and on some servers a 481. Forgotten clients, a second device, and stale sessions that have not yet timed out all consume slots. Setting the configured connection count below the plan limit, or closing the other client, restores service immediately.
DNS Resolution Failure: The client cannot translate the provider's hostname into an address, so no connection is even attempted. Causes include a typo in the server name, a resolver outage at the access provider, and DNS filtering on the local network. Providers publish round-robin records covering several machines, so a partial failure can also hand back an address that is out of service. Testing against another resolver confirms it.
ISP Port Blocking: The practice, common among access providers, of blocking outbound TCP 119, the plaintext NNTP port, which makes a news server appear unreachable even though the account is fine. This is why providers also listen on 563 for encrypted sessions and, on some networks, on 443 or 80, ports filtering rarely touches. Switching the client to 563 restores service and encrypts the transfer as well.
Disk Full: Downloads pause or fail when the destination volume runs out of space, and the client often reports only a generic write error. A Usenet workflow needs room for the incomplete folder, the extracted output, and the temporary files PAR2 repair creates, which together can approach three times the release size. Keeping incomplete and completed folders on the same small volume makes this far more likely.
Corrupt Archive: A RAR or 7z set that fails its own integrity check after download. The underlying cause is nearly always missing or damaged segments that PAR2 repair could not fully reconstruct, not damage in the archive as posted. CRC errors during extraction name the specific volume at fault, and re-fetching that one volume from a second provider is usually quicker than downloading the whole release again.
Bad NZB: An NZB a client refuses to load because its XML is malformed, truncated by an interrupted download, or wrapped in an HTML error page the indexer served in place of the file. Segment entries lacking message-ids draw the same rejection. Re-downloading the NZB usually fixes it, and a file that fails twice points at an indexer problem rather than anything in the newsreader.
Empty NZB: An NZB that parses correctly but lists no segments, so the queue accepts it and finishes instantly with nothing downloaded. The fault lies on the indexer side: a release whose articles are no longer held by any server, a failed subject-parsing run, or an API error page returned in place of the file once a quota was exceeded. Retrying the same NZB will not change the result.
Zero-Byte File: A file that leaves the queue at zero bytes, meaning every segment listed for it returned 430 and nothing decoded. On an old release this indicates articles expired past retention; on a recent one it suggests a removal between the indexer's scan and the download attempt. Files of a few kilobytes carrying the right name behave similarly and are usually placeholders rather than content.
Retry Loop: The condition where a client keeps re-requesting segments that will never arrive, holding connections open and stalling the rest of the queue. Aggressive retry settings and long server-priority chains both encourage it. Capping attempts at two or three per article and letting failed files fall through to PAR2 repair keeps the queue moving, since a segment absent from a spool does not reappear on a later request.
Duplicate Article: An article a server rejects at posting time because an identical message-id already appears in its history file. Propagation depends on that check: without it, an article echoing between peers would circulate indefinitely. On the reading side, several indexer listings pointing at the same release are a separate matter, handled by the download client's duplicate-detection setting rather than by any server.
Posting Failed: The response when a server refuses an article submitted with POST. Reasons include an account without posting rights, a missing or malformed required header, an article larger than the server permits, a moderated group that routes submissions to a moderator instead, and a message-id already present in the history file. The text following the response code usually names the specific reason.
Group Not Carried: The condition behind a 411 response: the newsgroup exists somewhere on Usenet, but the server being queried does not carry it. Providers choose which hierarchies to accept and commonly decline regional trees, defunct groups, and groups producing only spam. Adding a group by name in a newsreader does not create it. Checking the server's group list, or asking the provider to add the group, are the options.
Stale Header Index: A locally cached group index that no longer matches the server's article numbering, producing 423 responses when the client requests numbers that have since expired. Header-based readers left unrefreshed for weeks list articles that cannot be fetched. Resetting or re-downloading headers for the group realigns it. Indexers sidestep the problem entirely by listing releases with message-ids instead of per-server article numbers.
Clock Skew: A system clock far enough from real time to break things that depend on it. TLS certificates fail validation when the local date falls outside their validity window, raising certificate warnings against a perfectly good server, and posted articles carry Date headers that some servers reject. Enabling network time synchronization on the machine removes a whole class of otherwise confusing connection errors.
MTU Issue: A mismatch in maximum packet size along the network path that lets small NNTP exchanges succeed while bulk transfers hang, because oversized packets are dropped and the messages that would report it are filtered out. The symptom is a session that connects and authenticates, then stalls the moment article data flows. Common on tunnelled or PPPoE links; lowering the MTU on the client or router restores throughput.
Bufferbloat: Oversized queues in routers and modems that fill during a saturating download, adding hundreds of milliseconds of latency to everything else sharing the connection. A newsreader running many connections at full speed is a frequent trigger, which is why browsing and calls feel broken while a queue drains. Capping the client slightly below the line rate, or enabling queue management on the router, resolves it.
Disk I/O Bottleneck: The point at which storage rather than the network sets the pace. Unpacking a RAR set and verifying PAR2 both read and write heavily, and when they run against the same spinning disk the download is writing to, throughput collapses even on a fast line. Moving the incomplete folder to a separate drive or an SSD, and staggering post-processing, keeps the network side saturated.
CPU Bottleneck: The ceiling reached when a processor cannot keep up with TLS encryption, yEnc decoding, and PAR2 arithmetic at line speed. Low-power NAS boxes and single-board computers meet it first, often flattening out at a few tens of megabytes per second with the processor pinned. Hardware with AES acceleration removes most of the encryption cost; fewer connections and disabling direct unpack relieve the rest.

See the full Usenet glossary.

Errors & Troubleshooting

Put it into practice with the world's best usenet service