Thank you for the kind words.
@Scepterus, you might want to update this link to point to the Debian installation instructions instead.
I tried this initially and it didn’t work (something about not being able to find the bullseye release).
Your more detailed instructions got me through, and by comparing the detailed commands, I realized why it didn’t work in the first place.
Just did, thanks.
1 Like
I am about to shut down my TrueNAS system for the first time ever to modify some hardware. This would also be my first time rebooting ANY TrueNAS system.
A bit nervous because I remember people talking about stuff not surviving reboots on TrueNAS all the time. I don’t exactly remember what sort of data (app data or storage), setting (e.g. environmental variables), or applications went missing and why, and the conditions for their disappearance, so I can’t elaborate. However, I also later found out that TrueNAS Scale is an appliance and should not be used like an OS (e.g. apt was disabled for a reason). Regardless, I’m still glad that I followed this guide and ran Docker natively. I would love for all of my set-ups to be replicable, so doing things on Debian instead of the TrueNAS GUI is better in my opinion (of course provided it doesn’t break anything else).
Nevertheless, I should ask for some advice; and given that I started my TrueNAS journey here, I thought I’d ask in this thread. Do I need to worry at all? What should I look out for before and after I shut down? Should I rerun some commands after a reboot? Shoot me any advice that is peculiar to this set-up or just plain TrueNAS, as I also know close to nothing about the behavior of the latter!
Thanks!
That is a load of rubbish, that’s what they want you to think, so they don’t have to support people breaking TrueNAS and reporting bugs. As long as you know what you are doing, go ahead.
Do you mean CLI? because I might not fully understand what Debian has to do with what happens on TrueNAS.
No, if you follow this guide, everything will survive a restart for sure. As for your dockers, I can’t promise anything if you did not configure them to stop only when stopped or did not use volumes on your storage.
If you followed the guide, you’ll see there’s a script that runs post-init, that runs all the commands needed after a reboot.
My advice? Don’t be so afraid, if something breaks it’s a great opportunity to learn something new while figuring out how and why it broke. Dive in, and you’ll enjoy the journey, stay afraid, and you won’t even get started.
1 Like
Yes, you’re right – I was trying to make a GUI vs CLI comparison first and foremost, but then also a OS comparison (Debian being more common than TrueNAS). Isn’t TrueNAS running on Debian Linux?
Do you mind clarifying what this is about?
Can you also clarify what you mean here? I followed felixthecat’s guide to create all my Datasets on TrueNAS Scale (via the GUI); and I pointed volumes in my docker compose files to sub-directories of these Datasets. Is that okay?
Oh right, I did do that.
I get that. I love to learn, for sure; but I did also embark on this TrueNAS journey because I do actually need a NAS to store important files. Everything else – self-hosting Nextcloud, Jellyfin, etc – are nice-to-haves and secondary. I couldn’t care less if those or the OS broke, but I do actually want to preserve my data. If breaking the OS means losing my data, I also want to try to avoid that; unless I already know what to do to retrieve my data quickly in that situation, which I don’t – so that’s why I need to be careful right now as I gain more knowledge. For example, can I link a new install of TrueNAS Scale to existing files on a hard disk that used to live on a Dataset? Can I just pop my hard disks into a Windows system to retrieve my files?
I’m not averse to learning by breaking things; but definitely prefer to learn from other people’s experiences of breaking things, if that’s an option (and in the process save time and effort 
).
One additional question: How do you keep the post-init and docker compose files (did I miss anything else?) version-controlled (and therefore backed up) and easily “redeployed” in a different system? Everything seems scattered and Portainer is a GUI, which I am beginning to think is a bad idea (just for me). I do want to do this before I perform the system reboot.
I appreciate your reading and responding to my long messages, @Scepterus!
TrueNAS Scale is, TrueNAS Core runs on FreeBSD.
When you configure a docker you can specify the restart conditions, there are 3 options: always, unless-stopped and never. (could be more just of the top of my head.) so I usually use unless stopped, that way even if I restart the host, the dockers come back up as soon as the service is available to load them.
That’s fine, if you do not point them there they’ll stay inside the docker and will be lost if the container is removed.
It does not, you can always import the pool on a fresh install of TrueNAS or any other ZFS capable OS.
not unless you didn’t use ZFS. But look to the previous answer.
? You can just put them in one of your data set and have snapshots enabled on that, or you can also back those up on your PC. I don’t see a reason to do that, I can always just grab them again from my post.
Portainer is really nice for managing dockers, but as mentioned, it is optional.
Sure thing, if I can help, why not?
1 Like
Just updated to 22.12.1 so far here are the steps I needed to get up and running:
Re-Enable apt chmod +x /bin/apt*
touch /etc/docker.env
apt update and upgrade
and docker returned to normal.
I will update the init script to check if that file exists.
UPDATE:
updated the first post. The init script now checks if apt is executable, and if not makes it so, and also checks if docker.env exists and created it if not.
1 Like
So I signed up here to post a question regarding a write permissions issue between docker containers hosted on a remote Debian VM accessing my TrueNAS SMB share for persistent data storage. I found this guide when searching and this line has me thinking that my problems stem from this:
Do you know if this applies to any situation where docker containers are attempting to use remote SMB storage?
Thankfully, it appears that I have found an alternative way to implement what I want!. Thanks for the guide!
Hello and welcome to the forum!
To answer your question, yes, docker does not like SMB and SMB locks files and does not let them go (dumbed and watered down explanation I also got)
I am glad my guide helped you.
1 Like
Thanks! Unfortunately, I still find the same write permission issues after creating the dataset as Generic and not SMB for babybuddy (but portainer can run utilizing the share? this is exhausting) So I’ll make the post I originally intended to make.
BUT I will also be running through this guide to see if I can get the problem docker container to work with your implementation. Fingers crossed.
Did you bind that container to that share?
Good luck, I find my version has less hassle and as seen in the last update less chance to break between updates.
I had the smb share bound to /mnt/appdata folder in fstab on the host and /mnt/appdata/: bound in the container.
I did that for both portainer and baby buddy and portainer ran and was accessible/useable but babybuddy threw database write errors. Oh well. No biggy.
Followed your guide and happy to say got portainer and babybuddy up and running.
I did have to ssh in as root to get through step 4 and was unsure what uid gid to use for the babybuddy docker compose file.
Now to see if I can get Plex up and running with access to a second dataset for the media files.
Thanks again!
you mean Stage 4—Optional Upgrades ?
if so there’s a terminal on the webgui you can just use that.
Glad to hear it helped you.
Correct. I was initially going through under the admin login since I hadn’t changed the advanced setting to allow root to ssh.
Got permission denied. Are you root? errors when trying to install the packages.
The default user on TrueNAS is root, it was only in the last release that they allowed non-root users to log in to the webgui.
On a different subject, just updated the script to check all the steps regarding docker and other stuff. Would love it if someone could test it and let me know if it makes those things in the guide obsolete.
One note; I just upgraded to 22.12.1 and the Docker service would not start at all both during and after script execution.
output from journalctl -xe
failed to start daemon: Kubernetes Pool is not initialized
I ended up manually executing the docker upgrade steps in Step 4 and docker started without any issues .
Hey Jay, thank you for the feedback and welcome!
One question, did you use the updated script in the top post?
I may have the order of checks wrong, but I basically make sure all the steps are there every restart in that script.
When you say script execution, you mean you looked at the logs after a restart?
First of all, thanks @Scepterus for making this tutorial, I’ve been using this on this newly built TrueNAS box since January and it’s been great!
I had the same issue 3 weeks ago when I upgraded, but I think your updated script in STEP 3 fixes it based on the comments in the gist:
if [ ! -f /etc/docker.env ]; then
touch /etc/docker.env
fi
Hopefully, the next TrueNAS update goes smoothly. I know the next version (“Cobia”) set for late this year is making the switch to containerd and Docker will be removed. Can just re-install it with apt though and it stays that easy.
Hello and welcome!
I’m glad it helped you, I am working on adding more checked to the scripts to basically cover all the steps and check everything exists on every boot.
One of the steps I added to the script is the installation of docker based on the documentation I also linked in the guide. So the first time you’ll boot, you’ll get docker downloaded and installed again.
2 Likes