📖 Chapter 01 — The Family as a System
The NAS isn't for you. It's for your family. That changes everything about how you design it.
Learning Objectives
- Reframe "the NAS" as "the system the family uses"
- Apply the principle of least surprise to share and app design
- Identify the failure modes that come from designing for the technical user instead of the family
Introduction
You built the NAS. You know what a vdev is. You configured the snapshot schedule. You set up RAIDZ2 with 6 drives. The technical foundation is solid.
Now the harder problem: getting the rest of the family to actually use it.
This chapter is short but it sets the tone for the rest of Volume 2. The technical choices in Volume 1 (datasets, permissions, snapshots) were about what works. The choices in Volume 2 (apps, layouts, defaults) are about what people will use. Those are different questions.
The principle of least surprise
The most useful design principle for a family NAS is also the simplest: do what people expect.
When Mimi opens File Explorer, she expects to see the family photos in \\NAS\Photos. When she clicks the family photos folder, she expects to see folders organized by year or event. When she opens a folder named "Hawaii 2024," she expects to see the photos from that trip — not a ZFS dataset, not a sync conflict, not a half-uploaded file from her phone.
Every deviation from what people expect is friction. Friction is what makes people stop using the system and go back to iCloud or Google Drive. The job of Volume 2 is to remove friction.
Who is "the family"?
For TK's build, the family is four accounts (tk, Mimi, Lai) with very different relationships to the technology:
- TK (you): the admin, the technical user, the one who set this up. Has shell access, understands snapshots, knows what a dataset is.
- Mimi (spouse): the non-technical user. Knows the NAS exists, uses the family photos, doesn't want to learn anything new. Will use whatever is most convenient.
- Lai (sibling): the occasional user. Has a private dataset, logs in once a month, mostly ignores the system.
- Future users (children, friends, parents): people who haven't been onboarded yet but will be.
When you design the family experience, you're designing for Mimi. TK can handle complexity. Mimi will just leave.
For every decision, ask: "Would Mimi understand this without me explaining it?" If the answer is no, simplify. The next time TK is on a flight, the family needs to be able to use the NAS without him.
Three failure modes
Three ways a family NAS fails, all of which come from designing for the technical user instead of the family:
1. The "where do I put this?" problem
You set up a beautiful dataset tree with 15 carefully-named datasets. The family uses it for three days, then someone saves a file to their Desktop and forgets about it. After a month, half the family's data is on a laptop hard drive that wasn't backed up.
The fix: make the right place obvious. When Mimi plugs in her phone, the photos should go to Immich automatically. When she downloads a file from email, it should land somewhere that gets backed up. The default behaviors should be the right ones.
2. The "I can't find it" problem
You set up Immich with face recognition, OCR, location tags, albums, and search. The family uploads 5000 photos. Nobody can find the one they want because they don't know which app to use, which search to do, or even that the photo is in Immich.
The fix: make the obvious path the only path. If the family has a single way to access photos (Immich on the phone, the Immich web UI on the laptop), and you train them to use that, search will work because they're searching the right index. Don't give them five ways to access the same data; give them one good way.
3. The "it broke" problem
TrueNAS updates itself. An app updates itself. A drive reports a SMART warning. The system has a power blip. Now the family can't watch their movie.
The fix: make recovery automatic and invisible. Most issues should self-heal (services restart, snapshots roll back, scrubs repair). For the issues that can't self-heal, the family should know how to reach you. The support runbook ("if X happens, do Y; if Y doesn't work, message TK") should be short and live somewhere obvious.
The "Mimi test"
For every change you make, run the "Mimi test":
- Set up the change.
- Pretend you're Mimi — non-technical, busy, doesn't want to learn.
- Try to do the thing the change is supposed to enable.
- If you can't do it without instructions, redesign until you can.
Examples of the Mimi test in action:
- Setting up Immich on Mimi's phone. Can you do it in 5 minutes? Does it auto-upload by default? If not, redesign.
- Configuring the family calendar. Can Mimi see the family events in the iOS Calendar app without ever opening a Nextcloud interface? If not, redesign.
- Sharing photos with grandma. Can Mimi generate a public link and email it to grandma without leaving the Immich app? If not, redesign.
The hard parts of family IT
The conversation was honest about what's hard:
- Training people. Even with perfect software, you have to teach people how to use it. The teaching is more work than the setup.
- Supporting people. When something doesn't work, you have to be available to fix it. Plan for that time.
- Trusting the system. People won't put their photos in Immich unless they trust it. Trust comes from months of not losing things.
- Being the IT department. You are now the family's tech support. This is a real job, not a hobby.
None of these are problems you solve with technology. They're problems you solve with attention, communication, and being the person who notices when something's wrong before anyone else does.
Engineering Note
The hardest part of running infrastructure isn't the configuration. It's the human factors. The 6-drive RAIDZ2 with monthly scrubs and weekly SMART tests is the easy part. Getting the family to actually use the system — and to keep using it for years — is the hard part.
The good news: most of the work is done by being thoughtful upfront. The rest is being available when something goes wrong. Neither requires a network engineering background; both require showing up.
Summary
The NAS is a family system, not a personal project. Design for the least technical user in the house. Use the principle of least surprise. Make the right behavior the default behavior. Make recovery automatic. Be available. None of this is technical; all of it is what makes a home lab survive past the first six months.
Checklist
- ⬜ Identify the least technical person in the household. That's your primary user.
- ⬜ For every app you install, run the Mimi test: can the user do the thing without instructions?
- ⬜ Build a one-page "if X happens, do Y" runbook. Print it. Stick it on the fridge.
- ⬜ Schedule a recurring 30-min "NAS check-in" with the family. Once a month, briefly ask: "Is anything not working?"
Looking Ahead
Chapter 02 is the chapter on photos — the highest-value data, the app the family will use most, the one with the most "wow per minute of setup." Immich in production: setup, face recognition, albums, sharing, the migration off Google Photos.