How I Run Code-server via LinuxServer.io’s Docker Image on TrueNAS Scale

TureNAS Scale’s late 2024 release changes its native support for running containerized applications — they now run via Docker. This post is about how I run Code-server with Docker Compose and LinuxServer.io’s Code-server image.

This is my fifteenth post documenting images I use at home. You can also read about how I run the Unifi controller, how I run Plex, how I update DuckDNS, how I run Duplicacy, how I run Heimdall, how I run Librespeed, how I run Home Assistant, how I run NetBox, how I run Scrutiny, how I run OpenVSCode Server, how I run QDirStat, how I run WireGuard, how I run Z-Wave JS UI, and how I run netboot.xyz.

About LinuxServer.io

LinuxServer.io describes their organization as:

A group of like-minded enthusiasts from across the world who build and maintain the largest collection of Docker images on the web. At our core are the principles behind Free and Open Source Software. Our primary goal is to provide easy-to-use and streamlined Docker images with clear and concise documentation.

I’ve been using LinuxServer.io images for several years. That’s because they’re easy to use, and they’re clearly and concisely documented. I tend to check here first when I need a new image.

Why Code-server?

I am choosing to start with Code-server as my first application so that I can use it for building out future applications. I know there will be at least one. Running Code-server on the same machine as all of the other service data gives me an easy way to edit that data directly on that same machine.

Prepping the TrueNAS Scale Environment

First and most importantly — you’ll need to be on at least TrueNAS Scale version 24.10.0 (aka Electric Eel, released October 2024). This is the version that introduces formal Docker and Docker Compose support.

In this case, I am choosing not to use TrueNAS’s official or community apps. While those apps also run on Docker and Compose, I am choosing to run services entirely myself with a compose.yml file.

That said, Tom Lawrence of Lawrence Systems on YouTube has an extremely helpful guide for creating a dataset with permissions matching what the apps use. Even though we’re not using the apps, I’m going to mimic this since it makes sense to me.

Creating the Apps Dataset

Here are the steps I followed to create the Apps dataset — and these steps mostly match what Tom does in the above video:

1. From the dashboard, click on Apps in the left navigation.
   • Click the Configuration button in the top right.
   • Select `Choose Pool`.
   • Choose whatever pool you want and click Choose.
2. Click on Datasets in the left navigation.
   • Ensure there is a dataset with these properties:
   • Parent path: enter the path to your dataset
   • Name: `Apps` (or whatever you want to name it)
   • Dataset Preset: `SMB`
   • Create SMB Share: Checked (assuming you want to share via SMB. If not, skip this)
   • SMB Name: `Apps`
   • Select `Apps` and click on the `Edit` button in the `Permissions` section.
   • Click the `Add Item` button.
   • On the right, ensure `Who` is set to `User`.
   • For `User` select `apps`. (this is the key — under the hood the apps are using this user.)
   • Other settings can remain at default.
   • Click the `Apply permissions recursively` checkbox and click the `Save Access Control List` button.

Running the Image via docker compose

LinuxServer.io only officially supports running the image via docker run or, preferably, docker compose. Here is what the relevant section of my compose.yml file looks like:

networks:
  code-server:

  code-server:
    container_name: code-server
    image: lscr.io/linuxserver/code-server:4.95.3-ls243
    restart: unless-stopped

    env_file:
      - ./common.env
    networks:
      - code-server
    ports:
      - 3006:8443
    volumes:
      - ${SERVICE_DATA_DIR}/code-server:/config
      - ${SERVICE_DATA_DIR}:/service-data

About This Configuration

First, we define the network and image to use for this container. I always prefer to pin to specific versions when possible.

I then pull in the common.env file with environment variables common across all of my LinuxServer.io-based containers, like PUID and PGID.

Unlike most containers I run, this one does not need any specific environment variables set. It does support a handful of customizations, but I don’t need any of them.

Next, I specify the container’s port mappings. In this case, there is a sole mapping: port 8443 within the container is exposed to the outside world as port 3006. Why 3006? Because 3000-3005 are already taken by other services on this system. :)

Lastly, I have my volume mappings. The first is the typical /config directory required by LinuxServer.io images, which I have mapped to the directory with all of my service data. On this computer, service-data resides on the Apps dataset we created in the prior section. I also have the entire service-data directory mapped so that this Code-server instance can access and edit all of my service configuration on this computer.

And that’s it. Code-server containers here are easier to run than a lot of others, since it doesn’t require any hand tuning of environment variables.

Running Code-server on my TrueNAS Scale Instance

Configuring and running Docker containers is now pretty straightforward on TrueNAS Scale Electric Eel. At least for myself, I can now use the familiar docker compose syntax. And, in this case, having Code-server running as part of my compose stack improves the usability of my other service data.