# NCBI FTP Download Not Working? Troubleshooting Common Issues The single most common cause of an NCBI FTP download not working today is not a server problem at all. It is a web browser. Chrome and Firefox both removed support for FTP links, so a URL such as `ftp://ftp.ncbi.nlm.nih.gov/` that once opened a directory listing now fails silently or throws a connection error. The fastest check is to replace `ftp://` with `https://` in the same address. NCBI serves the same directory tree over HTTPS at `https://ftp.ncbi.nlm.nih.gov/`, so `https://ftp.ncbi.nlm.nih.gov/snp/` opens the same content that `ftp://ncbi.nlm.nih.gov/snp/` does, and the dbSNP database has been distributed through this anonymous FTP site since its early releases [1]. If the HTTPS version of the address works, your problem is the browser or the FTP protocol path, not the data. If it fails too, the problem is your network, your local tooling, or the path itself. This article walks through every common cause of NCBI FTP download failures in order of frequency, explains the mechanism behind each one, gives you a short diagnostic sequence, and ends with concrete commands and prevention practices that keep large reference data flowing into your pipelines. ## Start Here: The 60-Second Diagnosis ![Decision path testing HTTPS swap, command line reachability, hostname and path, and a second client to classify an NCBI FTP failure.](/article-images/illustrations/ncbi-ftp-download-not-working-triage-path.webp) Run these four checks before anything else. They resolve the majority of reports. 1. **Swap the scheme.** Take the exact URL that fails and change `ftp://` to `https://`. If `https://ftp.ncbi.nlm.nih.gov/` loads in a browser or responds to `curl`, move your workflow to HTTPS and skip most of this article. 2. **Test reachability from the command line.** Run `curl -I https://ftp.ncbi.nlm.nih.gov/` on the affected machine. An HTTP status line means the network path to NCBI is fine. A timeout points at your firewall, DNS, or proxy. 3. **Check the exact hostname and path.** The current public server is `ftp.ncbi.nlm.nih.gov`. Typos like `ftp.ncbi.nih.gov` or a stale path from an old script produce errors that look like server problems. 4. **Try a different client.** If your FTP client stalls, try `wget` or `curl` against the HTTPS mirror. If HTTPS also stalls, the problem is local or network level, not FTP specific. If all four checks pass but FTP still fails, continue to the cause-by-cause breakdown below. ## Troubleshooting Table: Symptom, Cause, Confirmation, Fix This table covers the failure modes you are most likely to meet. Each row is expanded in the sections that follow. | Symptom | Likely cause | How to confirm | Fix | |--|--|--|--| | Browser shows "connection refused" or nothing at all for `ftp://` links | Browser removed FTP support | The same path loads over `https://ftp.ncbi.nlm.nih.gov/` | Use HTTPS, wget, curl, or a dedicated FTP client | | Prompted for a username and password, or "530 Login incorrect" | Anonymous credentials entered wrong or a client requiring explicit login | Anonymous FTP expects the username `anonymous` and any email-style password | Log in as `anonymous` with your email as the password, or use a client that sends anonymous credentials automatically | | Client hangs after "Entering Passive Mode" or at the directory listing | Passive-mode data connection blocked by a firewall or NAT | Control connection opens but directory listing never arrives, then times out | Force passive mode in the client, widen the passive port range on the firewall, or switch to HTTPS | | "425 Unable to build data connection" or similar mid-transfer error | Active-mode data connection blocked by the remote side or your firewall | Errors occur only during data transfer, not login | Switch the client to passive mode, or abandon FTP for HTTPS | | Connection refused or timeout on port 21 but web browsing works | Outbound port 21 blocked on your network | `telnet ftp.ncbi.nlm.nih.gov 21` fails while HTTPS works | Ask your network team to allow port 21, or use HTTPS on port 443 | | Download stalls at the same point repeatedly, truncated or corrupt file | Idle control timeouts and long single-stream transfers | File size is short of the listed size, md5 check fails | Resume with `wget -c` or `curl -C -`, verify with the published md5 files, use Aspera for very large transfers | | "550" or "404" on a path that used to work | Directory reorganization or a mistyped case-sensitive path | Browsing the parent directory shows the current layout | Browse from the server root, use the Assembly resource's download links for genome files [2] | | Downloads work but crawl at a few hundred KB/s | Single-stream TCP transfer over a long network path | One connection saturates far below your link speed | Use Aspera or parallel segmented downloading for bulk data | | Everything works from home but not from the lab | Corporate proxy, TLS inspection, or egress filtering | Same command succeeds off network | Configure proxy variables, request a firewall exception, or use HTTPS | | Bulk crawling triggers errors or blocks | Server-side rate limiting of abusive clients | Many rapid sequential requests precede the failure | Slow the request rate, fetch directory listings once, use the NCBI datasets tooling | ## How to Use NCBI: Where FTP Fits Among the Databases A short orientation helps you confirm that FTP is even the right access route for the data you want. NCBI hosts dozens of linked databases, and most of them offer three access routes: interactive web interfaces, the FTP file servers, and programmatic APIs such as E-utilities. Knowing which route each database supports prevents many failed download attempts before they happen. Several NCBI databases publish their contents directly on the FTP site. dbSNP, the NCBI database of genetic variation, distributes its complete contents in multiple formats through anonymous FTP [1]. ClinVar, the public archive of human genetic variants and their interpretations of relationships to disease, provides downloadable files via FTP as well as programmatic access through E-utilities, and its files are organized around the variation-centric VCV accession system introduced with its variant-centric XML release [3]. The Assembly database, which provides stable accessioning and metadata for genome assemblies, links each assembly to sequence and annotation files on the [NCBI genomes](/blog/guides/ncbi-genomes) FTP site, so the recommended path to genome data runs from an Assembly record to a generated FTP link [2]. Clone DB makes reports of library, clone, and placement data available for download on its FTP site, covering genomic and cell-based libraries across more than a hundred eukaryotic taxa [4]. The HIV-1 human protein interaction database is another example, retrievable without restriction through both web-based downloads and FTP protocols [5]. The `/pub/` branch of the FTP tree is a general holding area that also hosts standalone software. For example, the RAId peptide-identification suite from NCBI's own [computational biology](/knowledge/bioinformatics/vaccinomics-and-the-future-of-personalized-vaccines) branch is distributed as source code and binaries under `ftp.ncbi.nlm.nih.gov/pub/qmbp/qmbp_ms/RAId/RAId_Linux_64Bit` [6]. The practical takeaway for anyone asking how to use NCBI effectively: identify the database first, then check its documented access routes. Genome assemblies go through the Assembly database and its FTP links [2]. Variant data comes from dbSNP [1] and ClinVar [3] FTP trees. When your target is a small set of records rather than a whole release, E-utilities or the NCBI datasets command-line interface is usually a better fit than FTP, because FTP is optimized for bulk directory downloads rather than record-level queries. ## NCBI FTP Download Not Working: Causes From Most Common to Rarest ### Cause 1: Your Browser No Longer Speaks FTP For years, pasting an `ftp://` link into a browser window was the default way people explored the NCBI FTP site. That workflow ended when the major browser engines removed FTP support. Chrome and Firefox have both dropped it, and other Chromium-based browsers inherited the removal. The symptom is confusing because the browser reports a generic connection failure or simply refuses the scheme, which reads like a server outage. The mechanism is straightforward. FTP is a separate application protocol from HTTP, with its own commands, two network connections per session, and no TLS by default. Browser vendors judged the protocol a liability and removed the client code. Nothing changed on NCBI's side. The files are all still there, and dbSNP [1], ClinVar [3], Assembly-linked genomes [2], Clone DB reports [4], and the HIV interaction database [5] are all still distributed through the same file tree. **Fix.** Two options work equally well. Replace the scheme and browse over HTTPS at `https://ftp.ncbi.nlm.nih.gov/`, which behaves exactly like a web folder. Or install a real FTP client such as FileZilla, lftp, or the command-line `ftp` and `lftp` utilities, and point it at `ftp.ncbi.nlm.nih.gov`. For scripted or bulk use, skip the browser entirely and go straight to the command-line fixes later in this article. ### Cause 2: Wrong Hostname, Path, or Anonymous Credentials Anonymous FTP is a convention, not a registered account, and clients handle it inconsistently. The NCBI public server expects the username `anonymous` and accepts any email-style string as the password. A client configured to prompt for credentials, a user who enters their own NCBI website login, or a script that supplies a blank password will all produce a `530 Login incorrect` response even though the server is healthy. Path problems produce a different signature, a `550` response or a web-style 404. Three things cause them. First, typos, including the very common `ncbi.nlm.nih.gov` misspellings. Second, case sensitivity, since FTP paths are case sensitive and assembly directories embed long underscore-delimited names that are easy to mangle. Third, reorganization. NCBI restructures parts of the FTP tree as databases evolve, so a path recorded in an old protocol document or [lab notebook](/knowledge/molecular-biology/lab-notebook) may no longer exist. The Assembly database is a good example of how to handle this correctly, because its record pages generate and maintain the FTP links for each assembly version, which means you never have to reconstruct a deep path by hand [2]. **Fix.** Confirm the hostname as `ftp.ncbi.nlm.nih.gov`. Configure the client for anonymous access, username `anonymous`, password in email format. When a path fails, browse one or two levels above it to see the current structure, or go through the parent database's web page, which links the canonical FTP location, as Assembly does for genome data [2]. ### Cause 3: Passive Mode Blocked by a Firewall or NAT ![Diagram of an FTP session: login on port 21 works, then the data connection fails in active or passive mode.](/article-images/illustrations/ncbi-ftp-download-not-working-passive-mode-branch.webp) This is the classic FTP failure and the one that most often confuses people, because login succeeds and then everything hangs. Understanding it requires knowing that FTP opens two connections. The control connection carries your commands on port 21. A second, data connection carries directory listings and file contents. In passive mode, the server tells the client which high-numbered port to use for the data connection. In active mode, the client tells the server to connect back to it. The failure mode depends on which direction your firewall blocks. If your client falls back to active mode, the server must open a connection inbound to your machine, which most firewalls and all NAT devices refuse. If your client uses passive mode, the server picks an ephemeral high port, and many corporate firewalls block the entire high-port range outbound. In both cases the symptom is the same: you authenticate, the client prints something like `Entering Passive Mode` or `150 Here comes the directory listing`, and then nothing happens until a timeout. The control channel is fine, the data channel is not. **Fix.** Force passive mode in your client. In FileZilla it is under transfer settings. In lftp, set `set ftp:passive-mode on` before connecting. In classic command-line `ftp`, issue `passive` after connecting. If passive mode still hangs, your network is filtering the passive port range, and the pragmatic answer is not to fight it but to switch to the HTTPS mirror, which runs over port 443 and passes through any firewall that allows normal web traffic. This is the single most reliable solution when you are on a managed institutional network. A short safety note on credentials here. Anonymous FTP needs no secrets, but if you configure an FTP client with stored credentials for any authenticated service, keep the client's password store protected and never paste connection logs into tickets or shared documents, because many clients echo credentials in verbose logs. ### Cause 4: DNS, IPv6, and TLS Interception Problems Three network-layer issues sit behind a minority of reports. DNS failures show up as "name or service not known" errors and are usually local, a resolver misconfiguration, a captive portal, or a VPN that hijacks resolution. Test with `nslookup ftp.ncbi.nlm.nih.gov` or `dig ftp.ncbi.nlm.nih.gov` and compare the answer from a public resolver against your default one. IPv6 problems are subtler. Some networks advertise IPv6 but deliver it poorly, and a client that prefers the IPv6 address of a dual-stacked host will time out even though IPv4 works. The tell is that a transfer begins after a long delay or fails only on one network. Force IPv4 with `wget -4` or `curl -4` and compare behavior. TLS interception matters only when you use encrypted transfer modes. Corporate security appliances that re-encrypt outbound TLS sometimes reject the server certificate chain during FTPS negotiation, producing certificate errors rather than timeouts. If you see certificate warnings inside an FTP client on a managed network, that is the signature. The fix is to talk to your network team, or again to sidestep with plain HTTPS through the same appliance, which is normally configured to work. ### Cause 5: Large Files Stalling Mid-Transfer NCBI distributes some very large artifacts. Whole-genome assembly packages, annotation releases, and the full contents of variation databases [1] can run to many gigabytes. Two mechanisms break long transfers. The first is idle timeout on the control connection. During a long single-file transfer the control channel is quiet, and middleboxes that track connection state, NAT gateways in particular, can drop an idle control session after a few minutes. The data transfer then loses its supervising channel and the client reports a stall or a reset. The second mechanism is plain packet loss and congestion on long network paths. A single TCP stream over a high-latency route can ramp up slowly and stall repeatedly, which is why a download from another continent often crawls while a local mirror of the same file saturates the link. Both mechanisms produce the same frustrating signature: the download dies around the same point, and restarting from zero loses hours. **Fix.** Use resumable clients and verify integrity. `wget -c URL` resumes a partial file. `curl -C - -O URL` does the same. lftp's `mirror -c` command resynchronizes a whole directory, picking up only missing or partial files. NCBI publishes checksum files, typically md5 format, alongside many of its data releases, so after transfer completes, run `md5sum -c filename.md5` in the download directory and confirm every line reports OK before you build anything on the data. For repeatedly interrupted bulk transfers, the Aspera route described below largely eliminates this class of failure because it uses a purpose-built transfer protocol rather than raw TCP. ### Cause 6: Server-Side Throttling of Bulk Downloads NCBI provides its data freely to the scientific community, but it protects shared infrastructure against abusive automated clients. Sustained, high-concurrency crawling of the FTP tree, hundreds of rapid sequential connections from one address, can trigger rate limiting or temporary blocking. The symptom is that a script that ran fine yesterday starts receiving connection refusals or slow responses today, while interactive use from the same network still works. **Fix.** Throttle your scripts. Fetch each directory listing once and cache it rather than re-listing for every file. Limit concurrent connections to a small number. Add delays between requests. If your use case is genuinely bulk, such as mirroring all RefSeq genomes, the supported alternatives are better anyway: the NCBI datasets command-line interface and E-utilities are designed for programmatic access, and E-utilities implements explicit usage policy limits for automated queries that you should honor in any script. For genome assemblies specifically, the Assembly resource's per-assembly FTP links let you fetch exactly one version of one assembly rather than crawling the whole genomes tree [2]. ### Cause 7: Controlled-Access Data That Anonymous FTP Cannot Reach A recurring source of confusion: some NCBI-hosted data is deliberately not on the public FTP site. Human genomic data with controlled access, governed through the dbGaP framework, requires documented authorization and is retrieved through a separate authenticated mechanism with project-specific encryption keys, not through anonymous FTP. If your target dataset is controlled access, no amount of FTP troubleshooting will help, because the failure is an authorization boundary working as designed. Confirm the access level on the dataset's page and follow the documented authorization and key-request process before attempting any download. ### Cause 8: Local Disk, Antivirus, and Proxy Failures The rarest causes are local. A full or quota-limited disk produces failures near the end of large transfers, with error messages that look network related. Antivirus and endpoint protection on Windows sometimes locks files during scanning and aborts long writes. Misconfigured proxy environment variables, a leftover `http_proxy` or `https_proxy` setting pointing at a dead internal proxy, break both wget and curl in ways that mimic server outages. Check each of these when everything else passes: `df -h` for disk space, a clean download of a small test file, and `env | grep -i proxy` for stale proxy settings. ## How to Fix NCBI FTP Download Not Working: Commands That Work These are the working solutions, ordered from most to least generally useful. All of them are standard tooling available on Linux, macOS, and Windows via WSL or similar environments. **HTTPS mirror with wget.** This is the default recommendation. The FTP tree and the HTTPS tree are the same content, and HTTPS traverses firewalls, proxies, and VPNs that break FTP. ``` wget -c https://ftp.ncbi.nlm.nih.gov/snp/latest_release/ ``` The `-c` flag makes every transfer resumable, which matters for anything over a few hundred megabytes. Wrap it in `-tries` behavior by simply re-running the command after an interruption, since `-c` picks up where the partial file left off. **HTTPS mirror with curl.** For single files and for environments where you want tight control: ``` curl -C - -O https://ftp.ncbi.nlm.nih.gov/pub/qmbp/qmbp_ms/RAId/RAId_Linux_64Bit ``` That path, which hosts the RAId mass-spectrometry identification software [6], is a real example of a file retrievable identically over FTP and HTTPS. `-C -` resumes from the current size of the on-disk file and `-O` writes it under the server's name. **lftp for directory mirroring.** When you need a whole subtree, lftp is the strongest open-source option and handles both FTP and HTTPS. For FTP, set passive mode explicitly: ``` lftp set ftp:passive-mode on open ftp.ncbi.nlm.nih.gov mirror -c /snp /local/path/snp ``` `mirror -c` continues an interrupted mirror, so a nightly cron job can maintain a local copy of a database release without ever restarting from zero. **Aspera for large transfers.** NCBI supports high-speed bulk transfer through Aspera's fasp protocol, which transfers over UDP with its own rate and loss control and routinely achieves far higher throughput than a single FTP or HTTPS stream on long paths. Install the Aspera Connect client, then follow the Aspera instructions published on the NCBI FTP site for the exact command form and key path for the current client version, since those details change with client releases. The command-line `ascp` tool then accepts NCBI paths of the same form as the FTP paths. For routine multi-gigabyte assembly downloads [2] this is the fastest supported route. **NCBI datasets command-line interface.** For genome and gene data, the datasets CLI avoids FTP path navigation entirely. You request data by accession or taxon and receive a zipped data package, with the underlying download handled by the tool. This is the modern entry point for the use case that Assembly and its FTP links [2] have traditionally served. **E-utilities for record-level retrieval.** When you need a handful of sequences or records rather than a database release, E-utilities fetch them directly. ClinVar, for example, explicitly supports programmatic access through E-utilities in addition to its FTP files [3], and record-level retrieval through E-utilities is faster and more precise than locating individual files in a large FTP tree. Scripts should respect the documented E-utilities usage limits, and adding an API key is the standard way to run automated queries responsibly. **Verification, every time.** Whichever route you use, confirm integrity before analysis. Download the md5 checksum files alongside the data and run: ``` md5sum -c your_download.md5 ``` A truncated or corrupted reference genome silently poisons every downstream step, so this one command is the cheapest quality control in bioinformatics. ## Alternatives When FTP Keeps Failing If FTP remains broken on your network after the fixes above, you lose nothing by abandoning it. The HTTPS mirror serves identical bytes over port 443. The Aspera path serves the same content with better throughput for large files. The datasets CLI and E-utilities cover programmatic access patterns from single-record fetches to bulk genome retrieval. In practice, most laboratories that hit persistent FTP problems end up standardizing on HTTPS plus Aspera and never look back, because both work through institutional firewalls that treat FTP as a legacy risk. ## Common Mistakes and Limitations - **Assuming the browser is still an FTP client.** The most frequent false alarm traces to testing FTP in Chrome or Firefox. Test with curl, wget, or a dedicated client before concluding the server is down. - **Retrying from byte zero.** Restarting a 50 GB transfer because it stalled at 90 percent wastes hours. Every recommended client above has a resume flag. Use it. - **Skipping checksums.** A transfer that completes without errors can still be wrong, especially after repeated resumes. Verify the md5 file that ships with the data before use. - **Assuming a failing path means failing data.** NCBI reorganizes FTP directories over time. Navigate from the server root or from the parent database's web page, as the Assembly resource does with its maintained per-assembly links [2], rather than trusting a path from an old document. - **Confusing FTP bandwidth limits with server outages.** A slow transfer is usually your network path or single-stream TCP behavior, not a fault at NCBI. Aspera exists precisely because single-stream transfers underperform. - **Crawling politely by accident.** Scripts that re-list directories before every file transfer multiply load on the servers and invite throttling. Cache listings and transfer in bulk. - **Expecting controlled data on the public site.** dbGaP-controlled human data requires separate authorization and keys. Anonymous FTP access is limited to public releases. - **A general limitation worth stating once.** Transfer behavior also depends on your specific institution's network configuration and on client versions that change over time, so a command that works on one lab machine may need adjustment on another. Individual setups vary, and when a managed network blocks the required ports, resolving it is a conversation with your local IT group rather than a technical fix you can apply alone. ## Preventing the Next Failure A few habits make NCBI data access boring and reliable, which is the goal. Pin your workflows to the HTTPS mirror rather than the FTP scheme. Add `-c` to every wget call and `mirror -c` to every lftp call by default. Run checksum verification as an explicit step in your pipeline, not as an optional afterthought. For scheduled bulk downloads, prefer lftp mirrors or the datasets CLI over hand-rolled FTP scripts, cache directory listings, and keep concurrency low. Check NCBI's FTP site release notes when a database announces a major update, since releases such as the ClinVar variant-centric XML reorganization changed file structures and accessions in ways that break hardcoded paths [3]. Finally, keep a one-line smoke test in your cron or CI setup, a small `curl -I` against `https://ftp.ncbi.nlm.nih.gov/`, so you learn about a network change from an alert rather than from a failed analysis run. ## Frequently Asked Questions ### Is NCBI FTP down or is it my network? Most reports of an outage turn out to be local. Run `curl -I https://ftp.ncbi.nlm.nih.gov/` from the affected machine. A status response means NCBI is reachable and the problem is your FTP client or protocol path, while a timeout points to your network, DNS, or proxy. ### What is the HTTPS alternative to NCBI FTP? Replace `ftp://ftp.ncbi.nlm.nih.gov/` with `https://ftp.ncbi.nlm.nih.gov/` and keep the rest of the path identical. The same directory tree is served over HTTPS, and it works in browsers, wget, and curl because it travels over port 443 like normal web traffic. ### Why does my browser fail on ftp.ncbi.nlm.nih.gov? Modern Chrome and Firefox removed FTP support entirely, so `ftp://` links fail in the browser even though the server is fine. Use the HTTPS mirror or a dedicated FTP client such as FileZilla or lftp. ### What username and password do I use for anonymous FTP? Use the username `anonymous` and any email-style string as the password. If your client prompts repeatedly or reports a 530 login error, it is usually sending the wrong credentials, not being blocked. ### Why do my downloads keep stopping at the same percentage? Long single-stream transfers stall when NAT devices drop the quiet control connection or when congestion interrupts the TCP stream. Resume with `wget -c` or `curl -C -`, verify the file against its published md5 checksum, and consider Aspera for very large transfers. ### Does NCBI support rsync for mirroring? No, the public NCBI file servers are not an rsync target, so rsync-based mirror scripts fail against them. Use lftp's mirror command over FTP or HTTPS, or the Aspera route for high-volume transfers. ### How do I download an entire genome assembly? Find the assembly in the NCBI Assembly database, then follow the download links on its record page, which point to the current sequence and annotation files on the genomes FTP tree. The datasets CLI offers the same content through a command-line interface keyed by accession or organism. ### Is Aspera faster than FTP for NCBI downloads? Yes, in most long-distance or high-volume cases. Aspera's fasp protocol manages transfer rate and packet loss directly over UDP, so it usually sustains much higher throughput than a single FTP stream, and NCBI provides it as a supported route for bulk data. ## Sources 1. [dbSNP: the NCBI database of genetic variation.](https://pubmed.ncbi.nlm.nih.gov/11125122/) 2. [Assembly: a resource for assembled genomes at NCBI.](https://pubmed.ncbi.nlm.nih.gov/26578580/) 3. [ClinVar: improvements to accessing data.](https://pubmed.ncbi.nlm.nih.gov/31777943/) 4. [Clone DB: an integrated NCBI resource for clone-associated data.](https://pubmed.ncbi.nlm.nih.gov/23193260/) 5. [Human immunodeficiency virus type 1, human protein interaction database at NCBI.](https://pubmed.ncbi.nlm.nih.gov/18927109/) 6. [Confidence assignment for mass spectrometry based peptide identifications via the extreme value distribution.](https://pubmed.ncbi.nlm.nih.gov/27153659/)