Installing SQL Server on Linux

Last Updated: November 2, 2026

SQL Server on Linux – one of those things that you can’t believe actually exists – two worlds you never thought would collide. For years, Microsoft and Linux were very much apart, until the announcement in 2015 that Microsoft Loves Linux. SQL Server on Linux was launched in 2017 and whilst I won’t get into the differences between the closed and open source communities, being a fan of both Microsoft SQL Server and Linux, I felt like I had to see what SQL Server on Linux was like.

With this in mind, let’s walk through the install process.

The Environment

I have spun up a modest VM for this test on my Proxmox hypervisor – a four-core Debian 13 Server with 8GB RAM and 4 x 32GB SCSI drives. Whilst the documentation only mentions Ubuntu, Red Hat and SUSE, I like to live by the sword and so will be installing on Debian. After all, Ubuntu is Debian-based so in theory, it should (probably!) work.

The Install

I will be installing SQL Server 2025 and will be looking to segregate data, log and tempdb files onto their own discrete volumes as is common on traditional Windows Server installs.

Pre-Requisites

Before we actually do anything on the install proper, I’ll set up some pre-requisites on my fresh Debian install. The detail of these steps are beyond the scope of the article but I will bullet point them below with the relevant commands for completeness and add some documentation to the references in this post.

Install SSH
- sudo apt install ssh
Enable the firewall and allow SQL Server and SSH ports
- sudo apt install ufw
- sudo ufw allow 1433/tcp
- sudo ufw allow 22/tcp
- sudo ufw enable
Partition all additional drives
- sudo fdisk /dev/sdb
- sudo fdisk /dev/sdc
- sudo fdisk /dev/sdd
- Once in the fdisk interactive prompt
  - n (add a new partition)
  - <defaults>
  - w (write table to disk and save)
Create ext4 file systems on each partition created above
- sudo mkfs.ext4 /dev/sdb1
- sudo mkfs.ext4 /dev/sdc1
- sudo mkfs.ext4 /dev/sdd1
Create mount points for the drives
- sudo mkdir -p /mnt/SQLSERVER/Tempdb
- sudo mkdir -p /mnt/SQLSERVER/Data
- sudo mkdir -p /mnt/SQLSERVER/Logs
Add the devices to fstab to mount them by UUID
- echo "UUID=$(ls -l /dev/disk/by-uuid | grep sdb1 | awk '{print $9}') /mnt/SQLSERVER/Data ext4 defaults 0 1" | sudo tee -a /etc/fstab
- echo "UUID=$(ls -l /dev/disk/by-uuid | grep sdc1 | awk '{print $9}') /mnt/SQLSERVER/Logs ext4 defaults 0 1" | sudo tee -a /etc/fstab
- echo "UUID=$(ls -l /dev/disk/by-uuid | grep sdd1 | awk '{print $9}') /mnt/SQLSERVER/Tempdb ext4 defaults 0 1" | sudo tee -a /etc/fstab
- sudo mount -a

Installing SQL Server

With that out of the way, we can get down to actually installing SQL Server. I followed the official Microsoft guide for Ubuntu following the 24.04 instructions.

The install process is (unsurprisingly) quite different from the traditional installer we are used to running on Windows. Whereas the Windows installer contains numerous setup pages to tweak the various options, on Linux, you install the binaries and then do all the other config (such as file locations) afterwards via a config tool.

The steps to install on Debian are:

Download the public key:

curl -fsSL https://packages.microsoft.com/keys/microsoft.asc | sudo gpg --dearmor -o /usr/share/keyrings/microsoft-prod.gpg

Add the repository:

curl -fsSL https://packages.microsoft.com/config/ubuntu/24.04/mssql-server-2025.list | sudo tee /etc/apt/sources.list.d/mssql-server-2025.list

Update the apt cache and install SQL Server:

sudo apt-get update
sudo apt-get install -y mssql-server

Here’s apt doing its thing:

That’s SQL Server installed. Now we have to run the config tool with the setup argument:

sudo /opt/mssql/bin/mssql-conf setup

Since this is SQL Server 2025, we can use the new Standard Developer Edition, so I’ll choose option 3 for that:

Then once we accept the licence terms, we choose the language and the sa password. I went for option 1 – English:

Then it’s time to create an sa password. We then get a fair bit of feedback via the terminal and very soon, we get a success message:

Let’s check what the state of the service is by using systemd:

systemctl status mssql-server

Connecting

Now everything is set up, let’s see if we can log in…

I’ll open SSMS on a Windows machine (there’s no Linux compatibility for SSMS at the time of writing) and connect to the instance via hostname:

Sure enough, I can connect and though it’s not clear from my dark mode screenshot, we can see that our server is actually represented by a cool Tux icon:

Configuring the File Locations

Firstly, let’s verify where the files for our system databases are created:

SELECT * FROM sys.master_files;

/var/opt is where they are stored. We know from our prerequisites that we want them at the respective locations in /mnt, so let’s see if we can change that.

The GUI options we can usually use to change the various directories are greyed out. When running SQL Server on a Windows host, changing these values runs an extended stored procedure xp_instance_regwrite which updates the Windows Registry, so I suppose it makes sense that these are greyed out.

To change these values on Linux, we need to do our configuration via the same mssql-conf tool we used earlier. The commands are as follows:

Change the data directory:

sudo /opt/mssql/bin/mssql-conf set filelocation.defaultdatadir /mnt/SQLSERVER/Data

Change the transaction log directory:

sudo /opt/mssql/bin/mssql-conf set filelocation.defaultlogdir /mnt/SQLSERVER/Logs

We get a helpful message to say that we need to restart for the change to take effect:

OK, let’s restart the service:

sudo systemctl restart mssql-server

Now we’ve restarted, let’s test it out by creating a database and then viewing sys.master_files again. Before we run the command though, we haven’t given our service account any permissions on the directories we created in /mnt. I’ll change the owner of the overall SQLSERVER directory I created:

sudo chown -R mssql:mssql /mnt/SQLSERVER

And now create the database:

CREATE DATABASE MyLinuxDatabase;

And once again check sys.master_files:

SELECT * FROM sys.master_files;

And we can see that with no drama, our files have been created on their respective volumes.

The tempdb directory is changed in the same manner as on Windows due to this being done via T-SQL:

ALTER DATABASE tempdb MODIFY FILE (NAME = [tempdev], FILENAME = '/mnt/SQLSERVER/Tempdb/tempdev.mdf');
ALTER DATABASE tempdb MODIFY FILE (NAME = [tempdev2], FILENAME = '/mnt/SQLSERVER/Tempdb/tempdev2.mdf');
ALTER DATABASE tempdb MODIFY FILE (NAME = [tempdev3], FILENAME = '/mnt/SQLSERVER/Tempdb/tempdev3.mdf');
ALTER DATABASE tempdb MODIFY FILE (NAME = [tempdev4], FILENAME = '/mnt/SQLSERVER/Tempdb/tempdev4.mdf');
ALTER DATABASE tempdb MODIFY FILE (NAME = [templog], FILENAME = '/mnt/SQLSERVER/Logs/templog.ldf');

Again, we can verify through sys.master_files after a service restart:

SELECT * FROM sys.master_files;

At this stage, we can tidy up by removing the tempdb files from the old location:

sudo find /var/opt/mssql/data -name "temp*" -delete

Conclusion

In this article, we installed Microsoft SQL Server on Debian 13. I’ll keep this server around on my test rig as I will probably do some further articles using it in future. In theory, this instance should work in the same manner as it does on Windows-based machines – stay tuned to find out!