David R. Longnecker

Some home improvement projects start with a plan. This one started with a storm.

We had some structural damage a while back, but with family, life, and everything else going on, it wasn’t a priority. At the time, the server room took the worst of it.

The good news: my offsite backups were intact. The bad news: every single service needed to be rebuilt from scratch. Pulling new wire, new servers, fresh drives, a stack of notes, and the sudden realization that I hadn’t stood up some services from zero in years.

This particular story is about setting up TrueNAS.

I’d been on an older SCALE build that just… worked. Set it up, forgot about it, trusted it. Coming back to a clean install of 25.10 (Community Edition, formerly SCALE) felt like returning to a kitchen someone had reorganized while you were gone. Everything’s still there, but nothing is where you expect it.

Two things took the most time on the rebuild:

• understanding what happened to familiar SMB settings, and
• figuring out why Windows Previous Versions stayed empty despite working snapshots.

Once those made sense, the protection setup came together better than what I had before.

If you’re rebuilding via SSH at 3am (like me), hopefully this saves you a few hours.

The New SMB Stack: Where Did Everything Go?

TrueNAS 25.10 restructured how SMB shares work. The old “No Preset” option is gone for new shares. Instead, you pick a purpose: Default Share, Multi-Protocol Share, Time Machine Share, and so on.

For most homelab use (a personal file share you access from Windows), you’ll create a Default Share. It works fine for basic access. What it doesn’t expose is anything interesting.

No recycle bin. No shadow copy settings. The UI is clean and minimal, and if you’re coming from an older version looking for those options, you’ll assume you’re missing something. You’re not. They’re intentionally gone.

The TrueNAS team’s reasoning is straightforward: Default Share prevents non-technical users from accidentally stacking conflicting VFS modules or misconfiguring options with subtle interactions. From a technical design perspective, this makes sense. From a homelab perspective, it’s mildly frustrating when you know exactly what you want and can’t find it.

To see what your current share looks like:

midclt call sharing.smb.query '[["id","=",YOUR_SHARE_ID]]' | jq '.[0] | {id,name,path,purpose,options}'

To find your share IDs:

midclt call sharing.smb.query | jq '.[] | {id, name, path}'

A Default Share will show "purpose": "DEFAULT_SHARE" and a minimal options object. This is your starting point for the next problem.

VSS / Previous Versions: A Dead End Worth Understanding

This one stung because the official docs are optimistic about it.

According to the TrueNAS 25.10 documentation on shadow copies, Windows Previous Versions should work automatically. Shadow copies are supposed to be enabled by default. You shouldn’t need to touch anything. Yay! 😊

What actually happens is different.

You set up snapshots. They run hourly. You can browse them directly at \\yournas\share\.zfs\snapshot\ and see historical versions of files sitting right there. ZFS is doing its job. Then you right-click a folder in Windows, go to Properties → Previous Versions, and get… nothing. The tab is empty. Every time.

The first thing to check is whether the shadow copy module is actually loaded. SSH into TrueNAS and run:

testparm -s | grep shadow

You’ll probably see this:

vfs objects = streams_xattr shadow_copy_zfs ixnas zfs_core io_uring

The module is loaded. The plumbing is there. Windows just won’t see anything.

The problem is a ZFS naming conflict.

Samba 4.22 (which ships with TrueNAS 25.10, running samba version 4.22.6-truenas) requires snapshot names in @GMT-YYYY.MM.DD-HH.MM.SS format for VSS enumeration to work with Windows. But ZFS snapshot naming prohibits the @ character entirely—ZFS reserves it for the dataset@snapshot syntax.

If you try to create a snapshot task with that naming schema:

@GMT-%Y.%m.%d-%H.%M.%S

TrueNAS will return: Value error, @ is not an allowed character in ZFS snapshot name.

So you’re stuck. VSS integration requires a naming format that ZFS physically cannot produce. Your snapshots are named auto-2026.02.20-01.53.00, which shadow_copy_zfs loads but Windows never sees because it doesn’t match Samba 4.22’s strict internal parsing.

The .zfs/snapshot folder browsing still works because that’s direct filesystem access, bypassing Samba’s VSS enumeration entirely. That distinction matters—you still have access to your snapshots, just not through Windows’ Previous Versions UI. You can recover any file by navigating to \\yournas\share\.zfs\snapshot\ and copying it back. It’s manual, slightly less polished than right-clicking and hitting “Restore,” but it works.

Getting the Recycle Bin Back: Switch to Legacy

Since Windows Previous Versions isn’t going to work in the current build, the next-best option for accidental delete recovery is a server-side recycle bin. Files you delete don’t disappear immediately—they land in a .recycle folder and you have time to grab them back.

This requires switching your share to Legacy purpose. Don’t let the name put you off. It doesn’t mean broken or deprecated. It means power user mode with the full Samba feature set exposed.

Step 1: Switch the share to Legacy

midclt call sharing.smb.update YOUR_SHARE_ID '{"purpose":"LEGACY_SHARE"}'
midclt call service.restart cifs

Verify it took:

midclt call sharing.smb.query '[["id","=",YOUR_SHARE_ID]]' | jq '.[0] | {id,name,purpose,options}'

You should now see "purpose": "LEGACY_SHARE".

Step 2: Enable the recycle bin

midclt call sharing.smb.update YOUR_SHARE_ID '{"options":{"recyclebin":true}}'
midclt call service.restart cifs

Step 3: Verify and test

From Windows, delete a file (regular delete and Shift+Delete both work). Then check:

\\server\yourshare\.recycle\yourusername\

The file should be sitting there. Windows will still show the “permanently delete” dialog—that’s normal. It just means the file isn’t going to the Windows Recycle Bin locally. The server is intercepting the delete and moving it on its own.

A few things to note:

• Recycle bin is per-user by default, so you’ll see .recycle/yourusername/ (your username is the one based on your NAS login, not your Windows login)
• recycle:touch is enabled automatically, updating the mtime at deletion time, which matters for age-based cleanup
• The .recycle folder will grow indefinitely without a cleanup policy

Setting Up Snapshots

The recycle bin handles “I accidentally deleted a file in the last 30 days.” Snapshots handle overwrites, corruption, or anything that happened further back.

In TrueNAS, go to Data Protection → Periodic Snapshot Tasks → Add.

The naming schema that works with the current build (for .zfs browsing, since VSS is out):

auto-%Y.%m.%d-%H.%M.%S

A reasonable retention policy for a roughly 1.5 TiB homelab pool:

• Hourly, keep 48 (two days of hourly recovery)
• Daily, keep 30 (a month of daily rollback)
• Weekly, keep 8 (two months of weekly checkpoints)

This won’t blow up a reasonably-sized pool. ZFS snapshots are space-efficient. They only store blocks that change after the snapshot was taken.

When you need to recover a file from a snapshot:

# On the TrueNAS box
cd /mnt/pool/dataset/share/.zfs/snapshot/

# List available snapshots
ls

# Browse into one
cd auto-2026.02.04_00-00/

# Find your file and copy it back
cp yourfile.docx /mnt/pool/dataset/share/

Or from Windows, navigate directly to \\yournas\share\.zfs\snapshot\ and browse to the version you need.

Cleaning Up the Recycle Bin

The .recycle folder won’t purge itself. Add a cron job to clean out files older than 30 days.

In TrueNAS: System → Advanced → Cron Jobs → Add

• User: root
• Schedule: Daily at 3:00 AM
• Command (dry run first, always):

# Preview what would be deleted (no actual deletion)
find /mnt/pool/dataset/share/.recycle -type f -mtime +30 -print

When the output looks correct, the actual cleanup command:

/usr/bin/find /mnt/pool/dataset/share/.recycle -type f -mtime +30 -delete && \
/usr/bin/find /mnt/pool/dataset/share/.recycle -type d -empty -delete

The second find cleans up empty directories after the files are gone. Both run as a single cron job.

The Protection Model That Actually Makes Sense

With recycle bin and snapshots in place, here’s the layered model:

Snapshots are not backups. They live in the same pool, on the same drives. If the hardware fails, the snapshots go with it. I learned that part the expensive way—the offsite backup that made this whole rebuild possible was already in place. Don’t skip layer three.

Recycle bin catches quick accidents. Snapshots handle the deeper problems: corruption, overwrites, anything that happened within the snapshot window. Offsite backup handles everything else, including the scenario that started this whole rebuild.

Quick Reference

For people landing here from a search at an inconvenient hour:

Find your share IDs:

midclt call sharing.smb.query | jq '.[] | {id, name, path}'

Check current share config:

midclt call sharing.smb.query '[["id","=",X]]' | jq '.[0] | {id,name,purpose,options}'

Switch to Legacy and enable recycle bin:

midclt call sharing.smb.update X '{"purpose":"LEGACY_SHARE"}'
midclt call sharing.smb.update X '{"options":{"recyclebin":true}}'
midclt call service.restart cifs

Verify shadow copy module is loaded:

testparm -s | grep shadow

Check snapdir visibility:

zfs get snapdir pool/dataset/share
zfs set snapdir=visible pool/dataset/share

Recycle bin cleanup command (30-day purge):

/usr/bin/find /mnt/pool/dataset/share/.recycle -type f -mtime +30 -delete && \
/usr/bin/find /mnt/pool/dataset/share/.recycle -type d -empty -delete

The VSS integration through Windows Previous Versions won’t work in 25.10 due to the Samba 4.22 / ZFS naming incompatibility. Browse .zfs/snapshot directly instead—it’s the same data, just without the polished Windows UI wrapper.

If that changes in a future build, I’ll update this post.