Comment

Comment on Tips for moving from TrueNAS to Debian for a NAS?

imma give you another opinion and start out with the unhelpful statement of „what’s best for you is gonna depend on what you need“

I‘ve never used debian as my personal NAS, but did manage a debian cluster at work. Compared to TrueNAS and later TrueNAS in a proxmox VM, debian is a lot more effort and in that sense „a hobby“.

Things that TrueNAS just handles for me without much work:

install correct and functioning legacy nvidia drivers into select docker containers. i used to use an old card and it worked like a charm. comparing that to my experience of manually installing nvidia drivers on debian, both on work servers as well as on old systems i found on the street, Debian is a real chore sometimes and requires fiddling where TrueNAS is a lot simpler.
TrueNAS apps are awesome. the catalogue is limited and sometimes it’s annoying how Truenas abstracts important things away (like the config file of HomeAssistant), but they are very useful too. they tend to be well-configured, updating is pretty and easy as is installing. you get automatic snapshots and rollback for each and every update. I have done systems administration as a hobby, but i kinda want my NAS to just work and that reliably. in that sense, Truenas has been better than debian for me.
setting things up can be annoying on truenas, but most is set and forget. I set up smart tests and they just work now. same for snapshots. configuring pools and vdevs is pretty easy and intuitive. this also is the case for harddrive power profiles and spindown. i‘ve never had to do this on debian, so all i can say is that truenas makes it all very accessible.
monitoring is easy-ish… if you wanna monitor from within the truenas UI, you’ll be pretty happy. there’s lots to see. some things you for some reason don’t though, and exporting makes you see even less info in some places. it’s a bit weird…
re-silvering is very simple
data replication is very nice. i’m using pcloud which has a somewhat annoying linux client. it’s a flatpak that only launches if it has a wayland (or x) session it can attach to, to display a window. kinda stupid if it’s a headless system or if i’m remoting into my desktop. still, truenas has me covered even in that regard as they can pull or push data (optionally well encrypted) to a variety of providers, including pcloud.

there probably is lots more, but i can’t think of anything else as of right now. I’ve used „plain“ Truenas scale for over a year and then switched to proxmox with a truenas VM when i built a new nas. the transition went pretty smoothly and i really like it. it does however add a layer of complexity you must be willing to deal with.

all things considered, i would like some things about truenas to work differently, but i would never wanna trade it. proxmox is very cool, and i like using it with a truenas VM, but i wouldn’t wanna use it without truenas i think. also i absolutely love debian and use it in many places. if i was running services on one machine and storage on another, id have the services on debian(or proxmox mby) and the storage on truenas, but as long as its just one device, its truenas.

additional thoughts:

i’ve heard good things about unraid but never tested it.
i’ve also seen many youtubers use CasaOS, but would recommend against it. i’ve not used it, but kept stumbling upon negative news in regards to it. it’s not as bad as omarchy/dhh, but it seems semi trustworthy.

source

Sort:hotnew top

TerHu@lemmy.dbzer0.com ⁨6⁩ ⁨days⁩ ago
on omarchy on dhh

source
CatLikeLemming@lemmy.blahaj.zone ⁨5⁩ ⁨days⁩ ago
On your point about it being “easy” to install containers via the app interface, are there any guidelines for how to configure them when all you’ve got for reference is a Docker Compose file?

A lot of stuff matches 1:1, but there are often oddities here and there, and I’m still not entirely sure of the correct way to configure storage. Some guides say to create datasets in the pool and then configure some to use the “apps” preset, while others should use “generic.” Others say to just use the automatic permissions checkbox, and others still tell you to check the “Use ACL” box. When I haven’t found a guide, I just created the datasets manually, set them to “apps,” and so far it has worked.

And when I want to use Docker containers normally, I’ve been advised against it. There used to be something called “jails,” but that was deprecated with the new Containers tab in the GUI. Apparently, that’s being dropped again for some reason, but the jails are still deprecated, and any time I search for how to use Docker Compose, I get so much conflicting info. Some say to just run docker compose as you would on a regular server via the command line, while others say that could break the system and tell me to just use VMs instead, and it’s all a mess.

The SMART stuff I mentioned was definitely my lesser worry, just a mild annoyance that tipped me over to consider switching, but the apps feel like I’m learning a whole new abstraction layer instead of just writing a Docker Compose file with input fields. Maybe that’s just a me problem though and I’m simply refusing to adapt, I am really not sure.

source
- TerHu@lemmy.dbzer0.com ⁨5⁩ ⁨days⁩ ago
  I get your point, it can be really quite confusing to go from a compose file or just general instructions and mby a docker run command to the settings of truenas.
  
  you mention jails and that’s a core (no pun intended) issue of truenas. Truenas core is based on BSD which uses jails, whilst truenas scale is based on debian and uses docker. then recently it was all combined back into one, based on linux. hence no jails, just docker.
  additionally, truenas scale was using kubernetes instead of docker until a year ago i’d guess. so what im trying to say is that whatever info you may find online could be very irrelevant if it’s for truenas core or truenas scale back in the kubernetes days.
  
  besides the ui, if you have a compose yaml and just wanna use that for setup, you can go to apps -> discover apps -> three dots next to custom app -> install via yaml. now this is a pain to find, but it is there an it works pretty well. if you hate how that editor works, you can just paste a stub there that imports a specific other yaml file and then you put all the relevant config into that one. this extra file can then be edited via the cli, copied, moved, and version controlled, which can be very convenient.
  
  regarding storage, using ixVolumes is perfectly fine. i prefer to have a generic dataset called apps that then contains specific datasets for each app i’m running. those specific datasets i set to the apps preset.
  beyond that, i’ve got more diverse setups too. for example audiobookshelf. the config and metadata storage live in an audiobookshelf dataset in the apps dataset, as described before. this apps dataset is on a small ssd pool.
  the podcasts and audiobooks themselves are stored on a larger HDD mirror. basically i have a media dataset there that uses the share preset and then within that i got an audiobooks dataset that uses the apps preset. that way audiobookshelf can use the books and i can easily access the directory via smb. additionally i run a cloud sync task from the data protection tab once a week that syncs all my audiobooks to pcloud.
  
  now all of that isn’t necessarily easy, but i find it easier and more intuitive than doing it all via the cli on debian. then again i’ve never used debian with some specialised nas ui as others have recommended.
  
  source