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.
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.