05. Advanced Container Settings
Before we leave this page, we need to dig a bit deeper. Click on “Advanced Settings”, which you will find below the “Network Configuration”.
In this lowest level of detail, you should find a page broken down in to 7 vertically stacked tabs, named: Commands, Networks, Environments, Labels, Storage, Runtime and Resources.
Let’s now work through each of these in turn:-
Commands
Leave the “Command” and “Entrypoint” text boxes in their “default” settings, and make sure that the “Allocate interactive processes (-i) for the container” and “Allocate TTY prcoesses (-t) for the container” are both set to active. We are going to rely on these two parameters being set ‘on’ when we come to set up and manage the container once it’s running.
Networks - IMPORTANT
In my case I wanted to access this container via the default [10Gb] network port on my NAS… but if you have a model with multiple network ports and connections, this is where you can specify which of the network ports on your NAS that your Docker container should be visible to your network.
The “Preparation and Warning” notes at the beginning of this guide included a requirement for a static IP address, valid on the local network – and this is where that value will be used.
Change the ‘Network Mode’ radio button selector from “Default (NAT)” to “Custom”. Allow the drop-down Combo Box to remain in “bridge”, then scroll the window down to reveal a couple of additional parameters tucked away at the bottom.
One of these is a check-box with the label, ‘Use a static IP address’. Activate that check-box and the installation window will change to give a 3-row data box with ‘IP address’, ‘Subnet mask’ and ‘Gateway’ as labels for the 3 rows. You will hopefully find that the Subnet mask and Gateway are pre-populated and greyed out – this data is sourced from the main network configuration parameters of your NAS. You should also find out that some of the 4 digits of your IP address – specifically the network address portion are also pre-defined and greyed out. In my case I am using a Class B network with network address 172.16.0.0, so I have just 2 parameters to fill in. Update the values in the “IP address:” parameter to match the address you previously obtained.
{{ Edit to Notes - Added April 3rd, 2026 }}
There’s a non-obvious but critical consequence of the decision you make here regarding whether to explicitly identify IP Addresses for DNS Servers or whether you are happy to allow the container to simply adopt the default DNS values set at your NAS/host level.
Suppose there is a future time where you need to make changes to your local DNS infrastructure and further suppose that those changes require you to amend the IP addresses for your DNS Servers on your network. If you create a new container with the DNS Server IP addresses set to “NAS Values”, then when you need to come to change to a new DNS host IP address, the only way you can do this is at the Host NAS Level. Under the hood, Docker provides a DNS proxy service to running containers. It uses a hidden IP address (127.0.0.11) and the DNS resolver details in containers will be set to this value.
The consequence here is that if you use “host based DNS” in this way, then when you come to change your DNS host value, you have given yourself no option except to migrate ALL your containers at the same time.
Conversely, if you explicitly set your DNS Server IP Addresses manually at this step in the process, then you grant yourself the ability to migrate “one container at a time” to a different IP address, and/or set different containers to use different DNS Servers [should you have that requirement].
The catch here - something that is not obvious at container creation time, is that once you create your container, your DNS decisions are “hard-coded” and cannot be changed.
Does this matter? Well, only you can answer that question. But if, say, you have a mix of “Production” and “Test” containers running in a single Docker instance [which, if you’re limited with respect to hardware, is a perfectly reasonable approach], then you’re going to be forced to migrate both test and production environments at the same time. That seems a bit counter-intuitive.
Take a moment to ensure that you have this configured in a way that is appropriate for your environment and make sure to document what you have done and why.
{{ End of Edit }}
Environments – CRITICAL
You can think of this element as for the specification of environment [run time] variables that the container is going to pass to MariaDB as/when MariaDB starts up. The values of these variables are essentially secure – as they are only visible here and inside the container itself, but they are critical.
That’s because you must provide a root password to the docker image of MariaDB as part of the initial configuration. To do this, click the “Add New Variable” button at the top right corner of the page in this tab. The name of the environment variable we have to create is “MARIADB_ROOT_PASSWORD” and the value we select should be something that conforms to conventional password rules. If you miss this step, your Container will not start. [OK, disclaimer. I just exaggerated when I said that you must provide a root password here. That’s not strictly true. One of the other support options is “allow no password”. I chose to write the instructions as I did above because I don’t want to encourage anyone to do anything that is insecure. The right action to take here is to use a generator to produce a secure password and use that. Please take a moment to reflect on the sensitivity of the data your DB will host and the environment in which your NAS operates. As I’ve noted before: “You do you”.
Labels
We’re going to leave the settings of this tab to their default values
Storage – IMPORTANT
In the section of this document with the title, “00b. Before We Get Started – A Data Gathering Requirement”, we considered the question of whether or not we want to create a permanent connection between the container’s internal file system and that of the NAS itself. This is where you get to decide which approach you will take.
If you’re currently performing a “pre-install” for “Option 3”…
– that is to say, deploying the MariaDB container so that you can jump in and have a look around, so that you know where to make a connection to your NAS file system, or if you’ve decided that you want to keep your MariaDB container completely isolated, you can skip Storage and leave it blank – simply jump down these notes to “Runtime” and continue.
If you’re currently performing the “second/full/final install” for “Option 3”…
– and/or you have otherwise determined the location of a folder within the MariaDB container that you wish to permanently “bridge” to the QTS file system, this is where you make that configuration. Please note: you can only make this decision at installation time – once “built” you cannot go back and edit this part of your container’s configuration. Whatever you decide here will be “final” for this particular container.
After selecting the “Storage” tab, click the “down arrow” to the right of the button labelled “Add Volume”. A pop-up window should appear below the button with three options in it – “Add Volume”, “Add Volume from Container” and “Bind Mount Host Path”. Select “Bind Mount Host Path” and note that a second “bind pair” appear in the main section of the window. This one will be differentiated with a small yellow “folder” icon – which signifies that it related to a folder native to QTS on the NAS. Click on the yellow folder icon and use the window which shows a path to actual, existing folders on the host NAS file system. Navigate through the file system until you select the remote endpoint that you want to be able to connect to from within your container. Ideally, you should make sure that the folder you select is part of an existing backup regimen – for example is enrolled within one of your existing HBS3 backups. Of course, you don’t need to have the QTS folder enrolled in an HBS3 backup before you add a MariaDB container, it’s just that if you want your exported .sql files to be archived, including the destination QTS folder in an HBS3 backup is the simplest way to do it.
Click in to the final data field, “Container:” and provide the path name to the location within the container on which we wish to mount the remote file system. (For users familiar with the soft-link operation of Linux, using the command “ln -s”, this is effectively the same thing). In our case, because our future selves were so helpful, we know that the internal folder we want to use is /var/backups. [Warning: if you’re reading this and preparing any version of MariaDB that is not 12.0.2, you really should be ignoring this hint and performing your own pre-install to check. Just saying].
Runtime
This tab controls the way that ContainerStation will spawn threads that execute the code in containers. Because ContainerStation is designed to operate three different types of container, this tab allows an administrator to help ContainerStation better understand how to interact with the executable code within. As we’re using a Docker image, we can let this remain with default values.
Resources
This tab allows you to decide whether you want to apply “upper limits” to the amount of hardware resource you are willing to allow this specific container to consume. It is likely to be very useful on larger NAS units and those with many users, because you probably don’t want one container to draw down all the available performance of the NAS. However, since this is going to be specific to your operating environment, there is no easy or obvious suggestion to make here. MariaDB recommend a minimum of 1Gb of RAM for basic operations. Stipulating CPU limits is going to be much harder, because different NAS models will have different CPUs installed.
If in doubt… either seek advice from an administrator, or try this as a rule-of-thumb… If you switch to “Limited” for any of the 3 options, the range of values will be pre-set based on your local hardware. Have a think about the range of users, workload and other applications running on the NAS in question and think about how much of the available performance you would be comfortable allocating to this one solitary container if it was “working hard”. In my case – a TVS-672XT used as a “home office” hub, I set limits at 25% of available resources across the board – and that has proven to be more than enough. Doing so gives me the confidence that even if my MariaDB container were to “go sideways” with a looping process, it will not kill my entire NAS – and, crucially, it will leave me with enough capacity/bandwidth to get in and figure out what is going wrong.
When you’re ready, click Finish.
In the background, ContainerStation will now download the “Mariadb:Latest” image from Docker Hub and then apply the various configuration parameters that we specified during the “create” process.
If we switch from the “Overview” tab of ContainerStation’s main display to “Containers” [via the left-side gutter margin], we should now see a single row in the main panel of the page, with a “Type” value of “Docker”, a “Name” value that matches the one provided earlier, and additional parameters – “Status”, “Application”, “Image”, “IP Address”, “Created On” and “Actions”.
At the bottom of the display we should also see a pair of tabs, “Logs” and “Status”.
If everything went [reasonably] well, then in the “Status” column of the table of containers, we should see a circular green icon and “Running”. Earlier in these notes, I mentioned that there was a way of checking to find out which TCP port our Docker instance of MariaDB was listening on – and this is it. Click on the “Logs” tabs and you should see a window with a black background and fairly small white text. Directly above the top right corner of this text window, you’ll see a small icon that looks like a square with an arrow pointing out of it towards the top, right corner. Click that arrow and the log window will expand to fill your browser. Unfortunately the content of this window isn’t rendered as HTML, so you can’t use “Ctrl-F” in your browser to search for the active port, but it should not be hard to find. In my case, the log contains the following:-
2025-11-06 7:59:15 0 [Note] Server socket created on IP: ‘0.0.0.0’, port: ‘3306’.
2025-11-06 7:59:15 0 [Note] Server socket created on IP: ‘::’, port: ‘3306’.
As I noted previously, when I tried to change the port via the Container setup options, I found that the value here remained stubbornly at port 3306. Eventually, I decided it wasn’t an issue since I was of course using a dedicated, static IP address and this was the only service the address would be likely to host. But I did say I would show you how to confirm the port that your MariaDB daemon is listening on and, well, this is it.
But: congratulations! You’ve just configured and installed MariaDB in Container station!
And it is currently absolutely useless!
Right now, all we’ve done is get the package downloaded and installed and got the main binary to successfully start executing. However, by default MariaDB won’t allow network connections and is supplied with just a single root/admin user. Now we need to perform a couple of very simple validation tests. The first is a simple network visibility test – just open a command prompt or shell prompt (from your workstation) and then issue the command,
ping {IP address}
where the {IP address} is the one that we applied to the container in the “Networks” tab of “Advanced Settings” and was based on the static IP address we obtained at the start of this guide. If we got our networking setup correct, we should see ICMP Echo packets returned to our workstation.
The second test, which is very helpful if you have the means to run it, is to perform an nmap scan. Nmap is a port scanning utility that can access a remote host and tell you whether or not the host is offering service for particular ports, such as TCP sockets. If your workstation is Windows based, you can download the nmap utility direct from the official Nmap web site . If your workstation is unix based, such as one based on GNU/Linux, you can almost certainly add the nmap utility direct from your local package manager.
Once you have the utility installed, simply check your container’s IP address. For example, I assigned the IP address 172.16.101.201 to my MariaDB container and when I run nmap against that IP address, this is returned:-
$ nmap 172.16.101.201
Starting Nmap 7.80 ( link to official nmap web site normally appears here ) at 2025-11-06 08:25 GMT
Nmap scan report for 172.16.101.201
Host is up (0.00012s latency).
Not shown: 999 closed ports
PORT STATE SERVICE
3306/tcp open mysql
Nmap done: 1 IP address (1 host up) scanned in 0.08 seconds
$
In this case I have only one open/active port at the IP address, but it shows that TCP Port 3306 is open (which means that a listener is monitoring the network stack and will respond to packets with that port ID) and we can also see that the listener is “mysql” – which is what we want.
This gives us a good level of confidence that our MariaDB engine is at least installed and running.