MongoDB is a modern, general purpose, document database, offering high performance, schema flexibility, and excellent high availability and scalability features. While MongoDB does offer the excellent MongoDB Atlas DBAAS cloud service, for some projects, a local database instance may be either preferred or required. 

Ubuntu is one of the most popular and widely supported Linux distributions available, making it a great host for a MongoDB deployment. However, you should avoid simply running sudo apt-get install mongoDB (or the equivalent used by other distributions’ package managers) to install it. 

Like much software, the version of MongoDB in the standard repositories for most Linux distributions is very old and most likely no longer supported. The steps in this guide will show you how to install the latest version from MongoDB’s own repositories.

As of the time of writing, Ubuntu 24.04 is the current Long-Term Support (LTS) release of Ubuntu, and MongoDB version 8.0 is the current stable version of MongoDB. Those are the versions I’ll be working with, but the instructions should be compatible with other combinations of Ubuntu and MongoDB. You can check out the currently supported combinations in the MongoDB PlatformSupport Matrix.

Ubuntu comes in both desktop (with the Gnome desktop) and server (console interface only) versions. In this tutorial, I’ll use console commands only so that they can be used on either Ubuntu version.

Are you looking for an automated platform to move your MongoDB data? Solve your data replication problems with Hevo’s reliable, no-code, automated pipelines with 150+ connectors.
Get your free trial right away!

What you will need

  • An Ubuntu 24.04 installation: This can be any hardware running on either x86_64 or arm64 processors. Almost all recent processors will be compatible, with the notable exception if you are installing on Raspberry Pi, where only the Raspberry Pi 5 and later have the required ARMv8.2-A microarchitecture.
  • A 6GB or larger USB stick: This is optional. For reasons I’ll explain in a moment, we might want to create a partition on your filesystem and, depending on how your disks are currently partitioned, we may have to reduce the size of your current root partition. Creating and temporarily booting from an Ubuntu Live USB stick is usually the easiest way to do that. 

Now we know what we need, let’s review the steps we’re going to follow:

  1. Modify disk partitions to make room to run MongoDB.
  2. Create XFS filesystems to run MongoDB on.
  3. Install and configure MongoDB. 

Let’s get started.

Effortless MongoDB Migration: Unlock Your Data’s Potential with Hevo!

Easily migrate your MongoDB data to a data warehouse or analytics platform with Hevo. Automate the entire process, maintain data accuracy, and gain powerful insights without the need for complex coding.  Hevo has helped customers across 45+ countries by offering:

  1. Real-time data replication with ease. 
  2. CDC Query Mode for capturing both inserts and updates. 
  3. 150+ connectors(including 60+ free sources)

Don’t just take our word for it—listen to customers, such as Thoughtspot, Postman, and many more, to see why we’re rated 4.3/5 on G2.

Get Started with Hevo for Free

Modify disk partitions to make room to run MongoDB

Linux supports several different filesystems, each with its strengths and weaknesses. It’s possible, common even, to have Linux systems with a mix of partitions using different filesystems, with each partition being used for a different purpose or application type. 

Without going into detail, the XFS filesystem is particularly well-suited for database-type workloads and is MongoDB’s recommended file system. Ubuntu, however, is based on Debian Linux, and the default filesystem on Debian is ext4. After installing Ubuntu, your system is almost certainly going to be running on an ext4 filesystem.

In reality, MongoDB will run just fine on ext4 for any workload you are likely to run in a test/experimentation/development environment, but you will get a warning message when logging in to the MongoDB shell if it is not running on XFS. If, like me, warning messages bug the heck out of you, or you are installing MongoDB for something more serious than a sandbox/development environment, the following steps will show you how to create a XFS filesystem in Ubuntu.

If you decide that setting up an XFS filesystem is overkill for your needs, you can jump straight to the Install and configure MongoDB section.

The instructions here make a couple of assumptions:

  1. Your disk storage is configured with a single physical disk, split into a boot partition and a second ext4 partition.
  2. All available storage has been allocated to the existing partitions.
  3. You do not have a second storage device that you intend to connect to the system to run MongoDB on.

These assumptions represent a worst-case scenario, but it is also a common scenario, as it’s probably what you will encounter if you use all the default options during installation of Ubuntu.

To check how your disks are partitioned, you can use the lsblk command. If your setup is similar to the scenario described, you should see something like this:

graeme@hpubuntu:~$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
nvme1n1     259:0    0 476.9G  0 disk
├─nvme1n1p1 259:4    0     1G  0 part /boot/efi
└─nvme1n1p2 259:5    0 475.8G  0 part /

The output from lsblk may show several ‘loop’ devices. These are virtual disks created by Ubuntu’s Snap package management system and, for our purposes, can be ignored.

This output shows I have a single drive, nvme0n1, with two partitions. If I then use the parted command, I can get further details of the partitions.

graeme@hpubuntu:~$ sudo parted
[sudo] password for graeme:
GNU Parted 3.6
Using /dev/nvme0n1
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print free                                                      
Model: INTEL HBRPEKNX0202AH (nvme)
Disk /dev/nvme0n1: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number  Start   End     Size    File system  Name  Flags        17.4kB  1049kB  1031kB  Free Space 1      1049kB  1128MB  1127MB  fat32              boot, esp 2      1128MB  512GB   511GB   ext4        512GB   512GB   110MB   Free Space

This confirms that I have a 1GB boot partition (formatted as fat32), and a second ext4 partition taking up almost all the remaining space on the disk.

Your system’s disk configuration may differ from the example outlined above. If you have secondary disks, or unallocated space on your main disk, that can be used for XFS partitions, you can adapt these steps to your specific setup.

For our scenario, the main challenge we have is that we are going to have to reduce the size of the existing ext4 partition to make room for our new XFS partitions, and, as this partition contains all the operating system files, we can’t simply unmount it temporarily to resize it—Ubuntu will report the file system is in use and prevent this.

To work around this, we are going to temporarily boot our system from a bootable Ubuntu Live USB stick. While doing this, the USB stick becomes the system’s primary storage device, and our internal hard drive should be accessible as an unmounted storage device, allowing us to resize its partitions.

If you have recently installed Ubuntu on your system, you may already have a Live USB stick that you used during the installation. However, if not, follow the instructions on Ubuntu’s website to create one now. 

Modify the partitions on your disk

WARNING: In the next steps, we will be reducing the size of the existing ext4 partition on your disk. Reducing the size of an existing partition always carries some risk of data loss. Therefore, please ensure that you have backed up (and verified the backup) all data on that disk before continuing. 

IMPORTANT: Before reducing the size of the existing ext4 partition, use the df -h command to note how much of the existing partition is currently in use. Do not attempt to reduce the size of the partition below this value.

Running df -h on our system gives the following output, showing we are using 12GB of the available 468GB:

ubuntu@ubuntu:~$ df -h
Filesystem                   Size  Used Avail Use% Mounted on
tmpfs                        1.6G   11M  1.6G   1% /run
tmpfs                        7.7G  8.0K  7.7G   1% /dev/shm
tmpfs                        5.0M  8.0K  5.0M   1% /run/lock
tmpfs                        1.6G  152K  1.6G   1% /run/user/1000/dev/nvme1n1p1                 1G  4.0K    1G   1% /boot/efi
/dev/nvme1n1p2               468G   12G  433G   3% /

Based on this output, a minimum of 12.1 GB is the amount you can reduce the ext4 partition to on this system. In reality though, you’ll want to leave the partition with plenty of space, as everything that is not either MongoDB data or MongoDB logs will continue to use this space.

Once your Live USB stick is ready, go ahead and boot your system using it. Note that when starting your system up, you might have to modify the boot sequence during the initial stages of  your machine’s power-on process to tell it to prioritize booting from the USB device over booting from the internal disk. Typically, the menu to modify this is accessed by pressing one of DEL, ESC, F11, or F12 during your machine’s POST process. 

IMPORTANT: When booting from the Live USB stick, when Ubuntu starts, it’ll walk you through an initial setup process. When asked if you want to “install Ubuntu” or “try Ubuntu,” be sure to select “try Ubuntu.”

Once Ubuntu has started from the Live USB stick, open a console window and run lsblk again  to inspect its disk and partition setup:

ubuntu@ubuntu:~$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0 119.2G  0 disk
├─sda1        8:1    0   5.9G  0 part /cdrom
├─sda2        8:2    0     5M  0 part
├─sda3        8:3    0   300K  0 part
└─sda4        8:4    0 113.3G  0 part /var/crash
                                      /var/log
nvme1n1     259:0    0 476.9G  0 disk
├─nvme1n1p1 259:4    0     1G  0 part
└─nvme1n1p2 259:5    0 475.8G  0 part 

As before, the output you see may include one or more “loop” devices and these can be ignored. The important things here are:

  1. A new disk, SDA, is listed with four partitions. This is the Live USB stick.
  2. Our internal disk, nvme0n1, is still listed, along with its two partitions, but they are no longer listed as being mounted. This is important as it means we will now be able to reduce the main ext4 partition to make space for our new XFS partitions.

Bearing in mind that the ext4 filesystem runs on top of a partition, the order of operations we need to perform to make space for our new partitions is:

  1. Reduce the size of the ext4 filesystem.
  2. Reduce the size of the partition the ext4 filesystem is running on to match the new size.
  3. Do a second resize of the ext4 filesystem to align it with the partition.

Because filesystems like ext4 reserve a certain amount of space for metadata, and because of the way partitions are aligned to storage devices, there is sometimes a discrepancy between the size we specify for the filesystem and the size that is needed when using partitioning tools to size the corresponding partition. The following steps should avoid any issues related to these discrepancies.

In our case, we have a 512GB physical disk. We’ll start by reducing the ext4 filesystem and its corresponding partition to roughly 350GB to create space for the new XFS partitions. 

Running as a superuser, use the e2fsck and resize2fs commands to reduce the file system size to 350GB:

ubuntu@ubuntu:~$ sudo e2fsck -f /dev/nvme1n1p2
e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/nvme1n1p2: 170296/31186944 files (0.2% non-contiguous), 5212636/124724544 blocks
ubuntu@ubuntu:~$ sudo resize2fs /dev/nvme1n1p2 350G
resize2fs 1.47.0 (5-Feb-2023)
Resizing the filesystem on /dev/nvme1n1p2 to 91750400 (4k) blocks.
The filesystem on /dev/nvme1n1p2 is now 91750400 (4k) blocks long.

Note that in the output from resize2fs, we are told the filesystem is now 91,750,400 blocks long and that each block is 4k (4096 bytes). This is important. resize2fs is reporting the block size in KiB, i.e., 1 KiB = 1024 bytes. However, the parted disk partitioning tool we are about to use uses metric values, i.e., 1 KB is 1000 bytes, 1 MB = 1000 KB, etc. We need to account for that difference when we specify the new size for the partition, or we’ll create a partition that is too small. Based on this, the size, in MB, we will need to specify in parted should be: 

(91,750,400 * 4096)/(1000*1000) 

Rounding up to a whole number, this gives 375,810 MB.

Running as a superuser, start the parted partitioning utility and select the device to partition:

ubuntu@ubuntu:~$ sudo parted
GNU Parted 3.6
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print devices                                                   
/dev/sda (128GB)
/dev/nvme0n1 (512GB)
(parted) select /dev/nvme0n1
Using /dev/nvme0n1
(parted) print
Model: INTEL HBRPEKNX0202AH (nvme)
Disk /dev/nvme0n1: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number  Start   End     Size    File system  Name  Flags
1      1049kB  1128MB  1127MB  fat32              boot, esp
2      1128MB  512GB   511GB   ext4

Next, resize the ext4 partition. Note that it is listed as partition two. The “end” value that we need to specify is the current start value, plus the size of the partition. In our case, that means an “end” value of (375,810 + 1128), or 376,938 MB:

(parted) resizepart 2 376938M                                            
Warning: Shrinking a partition can cause data loss, are you sure you want to
continue?
Yes/No? yes                                                              
(parted) print
Model: INTEL HBRPEKNX0202AH (nvme)
Disk /dev/nvme1n1: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number  Start   End     Size    File system  Name  Flags
1      1049kB  1128MB  1127MB  fat32              boot, esp
2      1128MB  377GB   376GB   ext4

With space now freed up, we’ll add a new 50GB partition to hold MongoDB logs:

(parted) mkpart                                                          
Partition name?  []? mdblogs                                             
File system type?  [ext2]? xfs                                           
Start? 377GB                                                             
End? 427GB                                                               
(parted) print
Model: INTEL HBRPEKNX0202AH (nvme)
Disk /dev/nvme1n1: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number  Start   End     Size    File system  Name     Flags
1      1049kB  1128MB  1127MB  fat32                 boot, esp
2      1128MB  377GB   376GB   ext4
3      377GB   427GB   50.1GB  xfs          mdblogs

Finally, we’ll add a second new partition to hold MongoDB data. This partition will be set to use the remaining space on the drive:

(parted) mkpart                                                          
Partition name?  []? mdbdata                                             
File system type?  [ext2]? xfs                                           
Start? 427GB                                                            
End? 512GB                                                               
(parted) print                                                           
Model: INTEL HBRPEKNX0202AH (nvme)
Disk /dev/nvme1n1: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number  Start   End     Size    File system  Name     Flags
1      1049kB  1128MB  1127MB  fat32                 boot, esp
2      1128MB  377GB   376GB   ext4
3      377GB   427GB   50.1GB  xfs          mdblogs
4      427GB   512GB   85.1GB  xfs          mdbdata

Close parted and do a check to make sure everything looks good using `lsblk`:

ubuntu@ubuntu:~$ lsblk                                                   
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0 119.2G  0 disk
├─sda1        8:1    0   5.9G  0 part /cdrom
├─sda2        8:2    0     5M  0 part
├─sda3        8:3    0   300K  0 part
└─sda4        8:4    0 113.3G  0 part /var/crash
                                      /var/log
nvme1n1     259:0    0 476.9G  0 disk
├─nvme1n1p1 259:6    0     1G  0 part
├─nvme1n1p2 259:7    0   350G  0 part
├─nvme1n1p3 259:8    0  46.6G  0 part
└─nvme1n1p4 259:9    0  79.3G  0 part 

Partition two is listed with its new smaller size, and our two new partitions are both listed as well, so all looks good.

As a final step in the resizing process, we do one more check with e2fsck and resize2fs to make sure the ext4 filesystem on partition two is fully aligned with the partition:

ubuntu@ubuntu:~$ sudo e2fsck -f /dev/nvme1n1p2
e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/nvme1n1p2: 170296/22937600 files (0.2% non-contiguous), 4693969/91750400 blocks
ubuntu@ubuntu:~$ sudo resize2fs /dev/nvme1n1p2

resize2fs 1.47.0 (5-Feb-2023)
The filesystem is already 91750400 (4k) blocks long.  Nothing to do!

If everything looks good, you can power down your system, remove the Live USB stick (as we won’t need it anymore), and then restart.

Create XFS filesystems to run MongoDB on

Your system will now boot from its internal storage. Once the boot process is complete, log in, open a console window, and use lsblk to inspect the disk and partitions:

graeme@hpubuntu:~$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
nvme1n1     259:0    0 476.9G  0 disk
├─nvme1n1p1 259:4    0     1G  0 part /boot/efi
└─nvme1n1p2 259:5    0 350G  0 part /
├─nvme1n1p3 259:6    0  46.6G  0 part
└─nvme1n1p4 259:7    0  79.3G  0 part 

In particular, we’re looking to confirm we have the two empty partitions ready to have `XFS` filesystems added.

As everything looks good, we can add the XFS filesystems. Start by making sure Ubuntu is fully up to date by running apt-get update and apt-get upgrade.

graeme@hpubuntu:~ $ sudo apt-get -y update
graeme@hpubuntu:~ $ sudo apt-get upgrade 

Now, we can install XFS itself:

graeme@hpubuntu:~ $ sudo apt-get -y install xfsprogs

If you recall the output from lsblk, our two empty partitions are nvme1n1p3 and nvme1n1p4. To create an `XFS` file system on each, run the following commands:

graeme@hpubuntu:~ $ sudo mkfs.xfs /dev/nvme1n1p3
graeme@hpubuntu:~ $ sudo mkfs.xfs /dev/nvme1n1p4

Now we have our two partitions with XFS filesystems, we need to mount them in the right locations within our directory structure. 

MongoDB writes logs to `/var/log/mongodb` and data files to `/var/lib/mongodb`, so let’s go ahead and create those:

graeme@hpubuntu:~ $ sudo mkdir /var/log/mongodb
graeme@hpubuntu:~ $ sudo mkdir /var/lib/mongodb

We can now mount the filesystems. nvme1n1p3 is our 30GB log partition, and nvme1n1p4 is our larger data partition, so the commands to run are:

graeme@hpubuntu:~ $ sudo mount /dev/nvme1n1p3 /var/log/mongodb
graeme@hpubuntu:~ $ sudo mount /dev/nvme1n1p4 /var/lib/mongodb

Confirm the mounts were successful:

graeme@hpubuntu:~$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
nvme1n1     259:0    0 476.9G  0 disk
├─nvme1n1p1 259:4    0     1G  0 part /boot/efi
└─nvme1n1p2 259:5    0 350G  0 part /
├─nvme1n1p3 259:6    0  46.6G  0 part /var/log/mongodb
└─nvme1n1p4 259:7    0  79.3G  0 part /var/lib/mongodb

The final step in this stage is to add entries to the fstab file so that the new XFS filesystems are mounted each time your system is booted. To do this, we’ll use the blkid command to get the PARTUUID of the two XFS partitions:

graeme@hpubuntu:~ $ sudo blkid /dev/nvme1n1p3
/dev/nvme1n1p3: UUID="7fee4d44-6820-4e90-861f-defd195e5205" BLOCK_SIZE="512" TYPE="xfs" PARTUUID="de9255b2-03"
graeme@hpubuntu:~ $ echo 'PARTUUID=de9255b2-03 /var/log/mongodb xfs defaults 1 1 ' | sudo tee -a /etc/fstab


graeme@hpubuntu:~ $ sudo blkid /dev/nvme1n1p4
/dev/nvme1n1p4: UUID="d8a6e88b-fba9-4719-96d4-327829c5cd8f" BLOCK_SIZE="512" TYPE="xfs" PARTUUID="de9255b2-04"
graeme@hpubuntu:~ $ echo 'PARTUUID=de9255b2-04 /var/lib/mongodb xfs defaults 1 1 ' | sudo tee -a /etc/fstab

Reboot your system and do a final check to confirm the XFS file systems have been mounted as expected.

Install and configure MongoDB

With our disk partitioned and XFS file systems in place, we’re now ready to install MongoDB.

At the time of writing, there are pre-built MongoDB 8.0 packages for both AMD_64 and ARM64 architectures for Ubuntu versions 20.04 LTS (“Focal”), 22.04 LTS (“Jammy”), and 24.04 LTS (“Focal”). While the instructions for installing each package are largely the same, in this article, we’ll assume you are installing on 24.04. It’s worth pointing out that supported platforms and versions will evolve, so it’s always worth confirming availability in the official MongoDB installation documentation.

To get started, install gnupg and curl if they are not already installed:

sudo apt install gnupg curl

Next, we need to install the MongoDB public GPG key:

curl -fsSL https://www.mongodb.org/static/pgp/server-8.0.asc | \
  sudo gpg -o /usr/share/keyrings/mongodb-server-8.0.gpg \
  --dearmor

Next, create an apt source list file for the Ubuntu 24.04 packages:

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

Reload the local package database:

sudo apt-get update

And, finally, install MongoDB:

sudo apt-get install -y mongodb-org

Yay—MongoDB is now installed! Before we can run it, though, we need to change ownership of the /var/log/mongodb and /var/lib/mongodb directories to a user and group created by the installation process.

sudo chown mongodb:mongodb /var/log/mongodb/
sudo chown mongodb:mongodb /var/lib/mongodb/

Ubuntu uses the systemd init system, so to start, stop, or check the run status of MongoDB, we use the systemctl command:

graeme@hpubuntu:~ $ sudo systemctl start mongod
graeme@hpubuntu:~ $ sudo systemctl status mongod
graeme@hpubuntu:~ $ sudo systemctl stop mongod

If you want MongoDB to start automatically each time your system boots, use the systemctl command to “enable” it:

graeme@hpubuntu:~ $ sudo systemctl enable mongod

Start MongoDB and use the systemctl status command to confirm it is running. If everything is good, you should now be able to connect using the mongosh MongoDB shell:

graeme@hpubuntu:~$ mongosh
Current Mongosh Log ID:    684f2bb6f32bce56dd69e327
Connecting to:        mongodb://127.0.0.1:27017/?directConnection=true&serverSelectionTimeoutMS=2000&appName=mongosh+2.5.2
Using MongoDB:        8.0.10
Using Mongosh:        2.5.2

For mongosh info see: https://www.mongodb.com/docs/mongodb-shell/


To help improve our products, anonymous usage data is collected and sent to MongoDB periodically (https://www.mongodb.com/legal/privacy-policy).
You can opt-out by running the disableTelemetry() command.

------
  The server generated these startup warnings when booting
  2025-06-15T21:21:41.026+01:00: Access control is not enabled for the database. Read and write access to data and configuration is unrestricted
  2025-06-15T21:21:41.026+01:00: For customers running the current memory allocator, we suggest changing the contents of the following sysfsFile
  2025-06-15T21:21:41.026+01:00: For customers running the current memory allocator, we suggest changing the contents of the following sysfsFile
  2025-06-15T21:21:41.026+01:00: We suggest setting the contents of sysfsFile to 0.
  2025-06-15T21:21:41.026+01:00: We suggest setting swappiness to 0 or 1, as swapping can cause performance problems.
------

test> 

So far so good, but we want to fix those two warnings that were generated. The first, about access control, is the important one, and we’ll handle that in a moment, but first, let’s get rid of the sysfsFile and swappiness warnings. These are related to changes in memory allocation in MongoDB 8 and there’s more details in the instructions to resolve them, but we’ll walk through the process here. As with running on XFS, this is also probably unnecessary for a small test or development environment, but for production environments and performance testing, this can make important performance improvements. It’s also worth reviewing the recommendations in the MongoDB Production Operations Checklist.

Start by creating a new systemd service file:

graeme@hpubuntu:~$ sudo vi /etc/systemd/system/enable-transparent-huge-pages.service
[Unit]
Description=Enable Transparent Hugepages (THP)
DefaultDependencies=no
After=sysinit.target local-fs.target
Before=mongod.service

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'echo always | tee /sys/kernel/mm/transparent_hugepage/enabled > /dev/null && echo defer+madvise | tee /sys/kernel/mm/transparent_hugepage/defrag > /dev/null && echo 0 | tee /sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none > /dev/null && echo 1 | tee /proc/sys/vm/overcommit_memory > /dev/null'

[Install]
WantedBy=basic.target

Reload the systemd unit files, then start and enable the new service:

sudo systemctl daemon-reload
sudo systemctl start enable-transparent-huge-pages
sudo systemctl enable enable-transparent-huge-pages

Restart MongoDB using systemctl restart mongod, then connect with mongosh again and verify the sysfsFile and swappiness warnings are no longer displayed:

graeme@hpubuntu:~$ sudo systemctl restart mongodgraeme@hpubuntu:~$ mongoshCurrent Mongosh Log ID:    684f419fa9869e92d969e327Connecting to:        mongodb://127.0.0.1:27017/?directConnection=true&serverSelectionTimeoutMS=2000&appName=mongosh+2.5.2Using MongoDB:        8.0.10Using Mongosh:        2.5.2
For mongosh info see: https://www.mongodb.com/docs/mongodb-shell/
------   The server generated these startup warnings when booting   2025-06-15T22:56:40.671+01:00: Access control is not enabled for the database. Read and write access to data and configuration is unrestricted------
test> 

Great—we can now deal with the access control warning and, as we said before, this one is important. 

By default, MongoDB is installed to allow anyone access to the database without authentication, but only from the device on which it is running. This means that, right now, we can only access it from the system it is running on. That might be fine if all access is from applications running on the same device, as could well be the case with deployments on something like a Raspberry Pi. In most cases, though, we will want to open up network access to MongoDB, and we will certainly want to restrict access to only authenticated users.

Let’s start by adding a user. Using the mongosh shell, run the following command:

use admin
db.createUser( { user: "admin",
    pwd: "YOURPASSWORDGOESHERE",
    roles: [ "userAdminAnyDatabase",
            "dbAdminAnyDatabase",
            "readWriteAnyDatabase"] } )

Replace YOURPASSWORDGOESHERE with an actual password (all the usual recommendations about password complexity and length apply). The roles granted to user admin by this command give them access to all data and allow them to administer other users, so keep that password secure. 

Now, we’ll modify MongoDB’s configuration file to tell it to enforce user authentication and to listen for connections on all of the system’s network adapters (rather than the default of listening only on its internal loopback adapter).

Using your preferred editor, modify /etc/mongod.conf. You need to change the bindIp setting from 127.0.0.1 to 0.0.0.0 (keep port set to 27017), and you need to uncomment the security: entry and add a new value under it, authorization: enabled:

net:
  port: 27017
  bindIp: 0.0.0.0

security:
  authorization: enabled

Note this is a YAML file, so the indentation is important.

Restart MongoDB once again and connect with mongosh—now, there should be no warnings:

graeme@hpubuntu:~$ sudo systemctl restart mongodgraeme@hpubuntu:~$ mongoshCurrent Mongosh Log ID:    684f43d2e35f3a3f7b69e327Connecting to:        mongodb://127.0.0.1:27017/?directConnection=true&serverSelectionTimeoutMS=2000&appName=mongosh+2.5.2Using MongoDB:        8.0.10Using Mongosh:        2.5.2
For mongosh info see: https://www.mongodb.com/docs/mongodb-shell/
test>

It’s worth pointing out at this point that what we’ve done is open up access to MongoDB from any device that can establish a network connection to your system. I’m assuming you are running on a home or office network with a firewall between you and the open internet. Ubuntu itself does not have any firewall protections enabled by default. If you want to add them, ufw is a pretty good option. Suffice to say, it’s almost never a good idea to expose a database server to the open internet, and certainly not one without authentication enabled. You will also want to enable TLS encryption if you’re deploying on, or enabling access from, anything other than your home network. Check out the MongoDB security checklist for more security advice.

To test network connectivity and authentication, move to another computer with `mongosh` installed (I’m using my Mac laptop), and attempt to connect to MongoDB on the system you installed it on. We’ll do this twice: once using an anonymous login and once using the credentials for the `admin` user we created. On both attempts, we’ll attempt to run a command to list all databases and verify the anonymous connection is blocked from doing so:

graeme@M-YYV2WV29DD ~ % mongosh --host 192.168.1.233Current Mongosh Log ID:    684f4534e70996626f69e327Connecting to:        mongodb://192.168.1.233:27017/?directConnection=true&appName=mongosh+2.5.2Using MongoDB:        8.0.10Using Mongosh:        2.5.2
For mongosh info see: https://www.mongodb.com/docs/mongodb-shell/
test> db.adminCommand({listDatabases: 1})MongoServerError[Unauthorized]: Command listDatabases requires authentication
graeme@M-YYV2WV29DD ~ % mongosh --host 192.168.1.233 -u "admin"Enter password: **********Current Mongosh Log ID:    684f45adaee80fbf1b69e327Connecting to:        mongodb://<credentials>@192.168.1.233:27017/?directConnection=true&appName=mongosh+2.5.2Using MongoDB:        8.0.10Using Mongosh:        2.5.2
For mongosh info see: https://www.mongodb.com/docs/mongodb-shell/
test> db.adminCommand({listDatabases: 1}){  databases: [    { name: 'admin', sizeOnDisk: Long('135168'), empty: false },    { name: 'config', sizeOnDisk: Long('73728'), empty: false },    { name: 'local', sizeOnDisk: Long('73728'), empty: false }  ],  totalSize: Long('282624'),  totalSizeMb: Long('0'),  ok: 1}

Congratulations—you now have a running deployment of the latest version of MongoDB on your Ubuntu system. So go, have fun, and create something amazing.

Share your experience of learning! Let us know in the comments section below!

mm
Former Director of Product Management, Hevo Data

Vivek Sinha has extensive experience in real-time analytics and cloud-native technologies. With a focus on Apache Pinot, he was a driving force in shaping innovation and defensible differentiators, including enhanced query processing, data mutability support, and cost-effective tiered storage solutions at Hevo. He also demonstrates a passion for exploring and implementing innovative trends within the dynamic data industry landscape.