Hello and welcome to the forum. As mentioned in the post, you’re not supposed to run that script, you’re supposed to put it in the post init startup scripts and restart.
That will fix you up, and you could continue.
Thanks for your reply. Following your suggestion I have put it in the post init startup scripts and restarted. But still getting the same errors when I try to check service:
admin@truenas[~]$ systemctl status docker.service
● docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/docker.service.d
└─override.conf
Active: failed (Result: resources) since Thu 2023-05-11 19:57:17 BST; 9min ago
TriggeredBy: ● docker.socket
Docs: https://docs.docker.com
CPU: 0
I note it says in the script that I am supposed to set storage driver for my version of Scale at line 26. I think it is already there as overlay2. Do I need to change anything else in the script?
I am running TrueNAS-SCALE-22.12.2
Thanks
You do not need to change that, my script takes care of that automatically.
I also updated the script notes to reflect that, and a minor tweak. try replacing it with yours now and we’ll see what happens.
I did actually use your script. The one in the update to Bluefin section. I will retry it by copy/paste again. The only thing I changed was the docker dataset path to /mnt/tank0/docker as my pool is tank0.
I am such a noob in linux that I think am doing someting very silly somewhere that exparts like you could never imagine someone could do. lol. Anyway, I will have another go later in the day.
Would there be someone on discord who could walk me through on a one to one basis?
Thanks
You could use the one in the OP, it is being updated constantly.
Also, you might want to start again and do each step from zero if you can.
Sorry, What is OG?
I meant OP, sorry. As in original post.
I was using the “old” method of running docker, i.e. just running the script w/o your modified one and enabling apt and I was wondering if it is safe to switch to your method when doing the upgrade. (I assume the answer is yes, but it does not hurt to double-check.)
Assume the following stack:
version: "2.1"
services:
unifi-controller:
image: lscr.io/linuxserver/unifi-controller:latest
container_name: unifi-controller
environment:
- PUID=1000
- PGID=1000
volumes:
- /mnt/tank/apps/unifi/config:/config
ports:
- 8443:8443
- 3478:3478/udp
- 10001:10001/udp
- 8080:8080
restart: unless-stopped
Your statement above means if the volume /config is not mounted to the storage /mnt/tank/apps/unifi/config, then the configuration is lost. How are other people mounting/using this config? (I am a bit confused about the extra warning, which is why I am asking this question.)
Yeah, it would work, assuming you update the script before the upgrade.
Yes, that is correct.
And people can not specify that mount, and the config would be saved in the container only. Hence when docker is removed (or rather k8, the truenas apps thing) their containers are wiped as well, as they are not configured the same.
1 Like
Why would this make a difference?
Do you mean going the full way of exchanging the script, enabling apt and then apply the upgrade? Or just change the script to the newer one?
It’s best to use the new script before the upgrade, as my new script makes sure everything that is needed is enabled. You may need to update docker after the upgrade, but it saves you the trouble to re-enable it.
If you upgrade and then change the script, you’ll need to restart again in order for it to fix things.
1 Like
Thank you again. So my way of upgrading would be:
Stage 1 is probably stopping all docker containers.
Stage 2 → does not exist
With Stage 3 being me replacing my script with yours and running the new script again.
my script
#!/usr/bin/env bash
#
# Enable docker and docker-compose on TrueNAS SCALE (no Kubernetes)
#
# This script is a hack! Use it at your own risk!!
# Using this script to enable Docker is NOT SUPPORTED by ix-systems!
# You CANNOT use SCALE Apps while using this script!
#
# 1 Create a dedicated Docker dataset in one of your zpools
# 2 Save this script somewhere else on your zpool, not in the Docker dataset
# 3 Edit line 20 of the script, set a path to the Docker dataset you created
# 4 You can now start Docker by running the script from the SCALE console
#
# For these changes to persist after SCALE reboots and upgrades, run the script at start-up
# Schedule this script to run via System Settings -> Advanced -> Init/Shutdown Scripts
# Click Add -> Type: Script and choose this script -> When: choose to run as Post Init
## set a path to your docker dataset
docker_dataset='/mnt/tank/apps/docker'
## HEREDOC: docker/daemon.json
read -r -d '' JSON << END_JSON
{
"data-root": "${docker_dataset}",
"exec-opts": [
"native.cgroupdriver=cgroupfs"
]
}
END_JSON
## path to docker daemon file
docker_daemon='/etc/docker/daemon.json'
if [ ${EUID} -ne 0 ]; then
echo "Please run this script as root or using sudo"
elif [ "$(systemctl is-enabled k3s)" == "enabled" ]; then
echo "You can not use this script while k3s is enabled"
elif [ "$(systemctl is-active k3s)" == "active" ]; then
echo "You can not use this script while k3s is active"
elif ! which docker &> /dev/null; then
echo "Docker executable not found"
elif ! chmod +x /usr/bin/docker-compose &> /dev/null; then
echo "Failed to make docker-compose executable"
elif ! install -d -m 755 -- /etc/docker &> /dev/null; then
echo "Failed to install directory: /etc/docker"
elif ! zfs list "${docker_dataset}" &> /dev/null; then
echo "Dataset not found: ${docker_dataset}"
else
echo "Checking file: ${docker_daemon}"
if test "${JSON}" != "$(cat ${docker_daemon} 2> /dev/null)"; then
echo "Updating file: ${docker_daemon}"
jq -n "${JSON}" > ${docker_daemon}
if [ "$(systemctl is-active docker)" == "active" ]; then
echo "Restarting Docker"
systemctl restart docker
elif [ "$(systemctl is-enabled docker)" != "enabled" ]; then
echo "Enable and starting Docker"
systemctl enable --now docker
fi
fi
fi
Stage 4 just as explained in the OP
Stage 5 being those steps again.
(2) can be omitted given that no container would be running anyway. (See Stage 1)
Is this correct?
Since you already did everything before only with a different script, all you basically need to do, is replace it with my script, restart, make sure everything is working then upgrade.
My script has checks to make sure the other steps are fine. I might revise the guide to rely more on the script when I get enough evidence that it works out of the box for these steps.
1 Like
Thanks for clarifying that. It seems I got confused with your previous statement but now everything is clear! 
1 Like
Glad to hear and good luck with your upgrade, let us know how it went.
1 Like
I’m currently running this script on 22.12.1, did anyone tried to upgrade to 22.12.3? Is it safe ?
Thanks for letting me know about the update.
Just tested, the update went ok, however, they did break something in preparation for the October release, when they plan to remove docker.
For some reason they treated dpkg the same as apt, and I got permission denied, which broke the link for docker source. Anyway, I updated the script to account for that, you can update it before you update TrueNAS, and when it boots wait a few minutes for it to fully execute.
They are planning on removing docker?
Yeah, in 23.10, it’s one of the commits they found, let me see if I can find it. If I do, I’ll update this post.
1 Like
On a sidenote, if I were to use your method. Wouldn’t docker have the rights to execute stuff as root? Lets say a pod is compromised and they successfully escalate. There would be nothing in between them and the data.
I may be naively thinking this is not the case with the default apps/k3s cluster. So please tell me if I am wrong.
Lets say I am wrong: does this method allow docker to be attached to a specific nic and disallow network communication with the host? As that is the main reason I am looking at alternatives for the default k3s cluster.