E: Unable to Locate Package MongoDB Mongosh: Causes and Proven Fixes

If you run sudo apt install mongodb-mongosh on Ubuntu or Debian and get back E: Unable to locate package mongodb-mongosh, your system is not broken and the package name is not wrong. The error simply means apt searched every repository index it currently knows about and found no package with that exact name. mongosh is MongoDB's modern shell (the replacement for the legacy mongo shell removed in MongoDB 6.0), and it is not published in the default Ubuntu or Debian archives at all. It ships only from MongoDB's own APT repository, from a downloadable .deb, or from npm. So this error is nearly always a repository configuration problem: a missing source list, a codename mismatch, a GPG keyring that apt refuses to trust, or an apt update that was never run after adding the source.

Quick Answer: The error means apt cannot find mongodb-mongosh in any enabled repository, because mongosh is not in the default Ubuntu or Debian archives. Fix it by adding MongoDB's official APT repository with a valid GPG keyring and the correct OS codename, running sudo apt update, then reinstalling the package.

How WebPeak Helps Teams Keep Database Environments Stable

Errors like this one rarely happen in isolation. They surface during server provisioning, a Node.js deployment, or a migration from a self-hosted MongoDB instance to a managed cluster, which is exactly where an experienced engineering partner saves days of trial and error. The team at WebPeak works with MongoDB-backed applications daily and treats shell tooling, repository pinning, and version compatibility as part of a repeatable provisioning process rather than a one-off fix. Their cloud solutions and migration services cover repository hardening and reproducible server builds, while their web application development services team keeps driver, server, and mongosh versions aligned so a working local environment does not break in production.

Why Is mongodb-mongosh Missing From apt in the First Place?

Apt can only install what is listed in its local package index, and that index is built exclusively from the repositories defined in /etc/apt/sources.list and /etc/apt/sources.list.d/. Ubuntu's universe component ships an old mongodb package (community server 3.6 or similar, depending on release) and Debian ships nothing current at all, so neither archive contains mongodb-mongosh. Run apt-cache policy mongodb-mongosh to confirm: if the output shows Installed: (none) and Candidate: (none) with no version table, apt genuinely has no source offering the package. That single command distinguishes a repository problem from a typo, and it is the first thing to check before editing any files.

There is a second, subtler cause worth knowing. MongoDB's repository is organised by distribution codename, so a source list written for jammy (Ubuntu 22.04) will return a 404 on noble (Ubuntu 24.04), and apt will silently continue with an empty index for that source. Derivative distributions make this worse: Linux Mint reports codenames like virginia or victoria from lsb_release -cs, and Kali or Pop!_OS can report codenames MongoDB never publishes. In every one of those cases you must substitute the upstream Ubuntu or Debian codename manually instead of trusting shell substitution.

What Is the Correct Step-by-Step Fix?

The reliable fix is to add MongoDB's repository with a modern signed-by keyring rather than the deprecated apt-key add method, which newer apt releases warn about or refuse outright. Follow these steps in order on Ubuntu 22.04 or 24.04:

1. Install the prerequisites: sudo apt-get install gnupg curl ca-certificates. A missing gnupg is a common silent failure point on minimal cloud images and Docker base images.
2. Import the signing key into a keyring file: curl -fsSL https://www.mongodb.org/static/pgp/server-8.0.asc | sudo gpg -o /usr/share/keyrings/mongodb-server-8.0.gpg --dearmor. The -f flag matters; without it curl writes an HTML error page into your keyring.
3. Add the source list with the correct codename: for Ubuntu 24.04, echo "deb [ arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-8.0.gpg ] https://repo.mongodb.org/apt/ubuntu noble/mongodb-org/8.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-8.0.list. Replace noble with jammy for 22.04, and use the debian bookworm path for Debian 12.
4. Refresh the index: sudo apt-get update. Read the output rather than skipping it. A 404 Not Found line naming your codename means the codename is unsupported for that MongoDB version.
5. Install and verify: sudo apt-get install -y mongodb-mongosh followed by mongosh --version.

If you only need the shell and not the server, install mongodb-mongosh alone; it has no dependency on mongodb-org-server. Teams that need the shell on an unsupported distribution should download the standalone .deb from MongoDB and install it with sudo dpkg -i, or use npm install -g mongosh, which is architecture-independent and useful inside CI containers.

Which Error Signature Maps to Which Root Cause?

Diagnosing this error quickly is mostly pattern recognition. The exact wording apt returns, combined with what apt update printed just before it, narrows the cause to one of a handful of situations. Use the table below as a triage reference before changing anything on the server.

What you see	Most likely cause	Fix to apply
Unable to locate package, no MongoDB line in apt update output	Repository source list was never created	Add the sources.list.d entry, then run apt update
404 Not Found on the repo.mongodb.org URL	Codename in the source list is unsupported for that version	Substitute the upstream Ubuntu or Debian codename
NO_PUBKEY or repository is not signed	GPG key missing, or dearmored to the wrong path	Re-import the key and match the signed-by path exactly
Candidate: (none) from apt-cache policy	Index built, but architecture excluded the machine	Add arm64 to the arch list on ARM servers
Package installs, then mongosh: command not found	Shell PATH cache is stale	Run hash -r or open a new shell session

What Do Experienced Engineers Do Differently Here?

The single most valuable habit is treating apt update output as diagnostic data rather than noise. In practice, almost every instance of this error announces its own cause in the update log two lines before the install command fails, and engineers who read that output resolve the issue in one attempt instead of pasting a series of unrelated commands from forum threads. MongoDB's own documentation is explicit that mongosh is distributed through its dedicated repository and as a standalone package, and that the legacy mongo shell was removed in MongoDB 6.0, which is why so many older tutorials produce this exact failure when followed on a modern release.

A second habit worth adopting: pin the MongoDB major version deliberately. The repository path encodes the version (mongodb-org/8.0), and mixing a 6.0 source list with an 8.0 keyring is a frequent cause of confusing signature errors on teams that copy provisioning scripts between projects. Based on repeated production experience, hardcoding both the codename and the version in an infrastructure-as-code template, rather than deriving the codename with lsb_release -cs at runtime, eliminates the majority of these incidents because it removes the one variable that silently changes when a base image is upgraded. If you also run automated deployments, keep an eye on repository trust as a security concern, not just a convenience one; unsigned or third-party mirrors are a genuine supply-chain risk, and specialists such as cloud infrastructure teams routinely audit source lists for exactly that reason.

Key Takeaways

• mongosh is not in the default Ubuntu or Debian archives, so the error is a repository problem, not a typo.
• apt-cache policy mongodb-mongosh confirms in one command whether any source offers the package.
• A 404 in apt update output naming your codename means that codename is unsupported for the MongoDB version you selected.
• Use the signed-by keyring method; apt-key add is deprecated and fails or warns on current apt versions.
• On unsupported distributions, install the standalone .deb or use npm install -g mongosh instead of forcing the repository.

Frequently Asked Questions

Why does apt say it cannot locate the package mongodb-mongosh?

Because mongosh is not published in the default Ubuntu or Debian repositories. Apt only installs what is in its local index, and that index is built from your configured sources. Until you add MongoDB's official APT repository and run apt update, apt has no record of the package existing.

Can I install mongosh without installing the MongoDB server?

Yes. The mongodb-mongosh package is standalone and does not pull in mongodb-org-server. This is the normal setup for developer laptops, jump hosts, and CI runners that connect to a remote cluster or MongoDB Atlas but never run a local database instance.

What codename should I use on Ubuntu 24.04?

Use noble, and pair it with a MongoDB version that supports it, such as 8.0. Older repository paths like 6.0 do not publish a noble directory, so apt returns a 404 and builds an empty index, producing the same unable-to-locate error you started with.

How do I fix this on Linux Mint or another Ubuntu derivative?

Do not use lsb_release -cs, because derivatives report their own codenames that MongoDB never publishes. Look up the upstream Ubuntu release your version is based on and hardcode that codename, for example jammy or noble, in the source list before running apt update.

Is installing mongosh through npm safe for production servers?

It is functionally fine and useful for containers, but the APT package is preferable on long-lived servers because it receives updates through your normal patching workflow. If you use npm, pin the version explicitly and include it in your dependency audit process like any other package.

Conclusion

The most important decision here is to stop treating this as an installation error and start treating it as a repository configuration check. Verify with apt-cache policy, read the apt update output, confirm your codename and MongoDB version actually pair, and add the key using the keyring method rather than a deprecated command copied from an old guide. Do that once and the fix takes under two minutes on any Debian-based system. Codify the working source list in your provisioning script so the next server, container, or teammate never hits the same wall, and your MongoDB tooling stays predictable across every environment you run.