Hi everyone,

I’m relatively new to Unraid and have been using Copilot to help me troubleshoot this, but I’ve hit a wall and could really use some guidance from the community.

My goal:

Expose Btrfs snapshots to Windows via SMB “Previous Versions” using shadow_copy2 for a specific directory in my user share.

System summary

- Unraid 7.2.2 (stable)

- Btrfs pool with regular snapshots created via User Scripts (every 15 minutes + daily retention)

- Snapshots stored under .snapshots/... and fully functional

- Windows clients can access the share normally

- No SimonF Snapshots plugin currently installed

- No custom SMB Extras active

- Share is healthy and accessible

The problem

I cannot get shadow_copy2 to apply to a single specific SMB share.

On Unraid 7.2.2, every attempt to inject the required VFS parameters either:

- ends up in the global section instead of the share, or

- creates a duplicate share section, which causes Samba to mark the share “available = No”.

As a result, Windows “Previous Versions” shows nothing, even though snapshots exist and are valid.

What I’ve already tried / ruled out

1. Manual SMB overrides

I’ve tried multiple approaches:

- smb-extra.conf

- smb-local.conf

- per‑share include files

- parameter‑only includes

- global includes

- section‑based overrides

On Unraid 7.2.2, all of these either:

- inject into [global] instead of the share, or

- create a second [DataDisk] section, which breaks the share.

It appears Unraid 7.x changed the SMB layering so that per‑share overrides are no longer honored.

2. Per‑share SMB Extras

This feature appears to have been removed in 7.x, so I cannot use it to inject shadow_copy2 safely.

3. SimonF Snapshots plugin

I want to be very clear:

I have huge respect for the work plugin authors do for the community.

This is not a complaint — just an observation of behavior on 7.2.2.

When I tried the plugin:

- The GUI hook for the Snapshots tab did not appear

- The SMB include file was not generated

- The cron integration conflicted with Unraid’s scheduler

- The plugin’s SMB injection mechanism didn’t seem to fire

Because of this, I uninstalled it to avoid further conflicts.

If the plugin is still the intended path on 7.x, I’d be very happy to reinstall it and configure it manually.

4. Share configuration issues

I’ve verified:

- The share path exists

- Permissions are correct

- No CRLF issues in the share config

- No invalid characters in the share name

- No disk include/exclude conflicts

- The share is accessible from Windows normally

So the share itself is healthy.

5. Snapshots themselves

Snapshots are created correctly and retained as expected.

I can restore files manually from the server without issue.

The only missing piece is SMB exposure.

Current behavior

- Snapshots exist and are valid

- I can restore files manually

- Windows “Previous Versions” shows nothing

- shadow_copy2 never appears inside the share

- It always ends up in [global]

- I cannot find any supported way to inject per‑share VFS parameters on 7.2.2

My question

Is there any supported or working method on Unraid 7.2.2 to expose Btrfs snapshots to SMB via shadow_copy2?

Or is this currently broken due to changes in the SMB config layering in 7.x?

If the SimonF plugin is still the intended path, is there a manual way to enable the SMB include file even though the GUI tab doesn’t appear?

Any guidance would be hugely appreciated.

Thanks,

Ironthorne

I've only seen this work with ZFS snapshots

Calling the samba mod shadow2 is not enough.

ZFS:

vfs objects = shadow_copy2

shadow: snapdir = .zfs/snapshot

shadow: sort = desc

shadow: format = zfs-auto-snap_%S-%Y-%m-%d-%H%M

shadow: localtime =

yes

https://forum.level1techs.com/t/zfs-on-unraid-lets-do-it-bonus-shadowcopy-setup-guide-project/148764

I also have something lost on the form that went over doing this with unraid samba.

U raid samba is not stock samba and you may need to write your own SMB to accomplish this ..

Edited January 16Jan 16 by bmartino1

On 1/16/2026 at 5:56 PM, bmartino1 said:

I've only seen this work with ZFS snapshots

Calling the samba mod shadow2 is not enough.

ZFS:

vfs objects = shadow_copy2

shadow: snapdir = .zfs/snapshot

shadow: sort = desc

shadow: format = zfs-auto-snap_%S-%Y-%m-%d-%H%M

shadow: localtime =

yes

https://forum.level1techs.com/t/zfs-on-unraid-lets-do-it-bonus-shadowcopy-setup-guide-project/148764

I also have something lost on the form that went over doing this with unraid samba.

U raid samba is not stock samba and you may need to write your own SMB to accomplish this ..

Thanks for the detailed reply, really appreciate you taking the time.
For my setup I think switching everything over to ZFS would be overkill, and I’m definitely not confident enough to start rewriting SMB configs by hand.
I’ll stick with the simpler approach for now, but your explanation was super helpful.

had to do a little more digging on this.

as Calling the samba mod shadow2 is not enough.

why ZFS worked why btrfs doesn't

vfs objects = shadow_copy2

shadow: snapdir = .zfs/snapshot

shadow: sort = desc

shadow: format = zfs-auto-snap_%S-%Y-%m-%d-%H%M

shadow: localtime = yes


What shadow_copy2 actually needs

shadow_copy2 does not talk to Btrfs or ZFS directly. It only:

• Enumerates directories

• Matches them against a timestamp format

• Exposes them as “Previous Versions” over SMB

So everything depends on how your snapshot directories are named and where they live.

ZFS vs Btrfs (why your ZFS example doesn’t translate)

Your ZFS config works because ZFS auto-snapshots look like this:

.zfs/snapshot/zfs-auto-snap_2024-01-26-1200/

ZFS provides:

• A fixed .zfs/snapshot directory

• Predictable naming

• No extra bind-mount work

Btrfs does NOT do this automatically.

On Unraid, Btrfs snapshots usually look like one of these, depending on tool:

A) Snapshots in a .snapshots/ directory (common)

/mnt/cache/appdata/.snapshots/2024-01-26_12-00/

B) Snapshots in a custom directory

/mnt/cache/.snapshots/sharename/2024-01-26_12-00/

C) Snapshots created outside the share (most common Unraid pitfall)

If the snapshots are not inside the share path, Samba will never see them.

Absolute rule for Unraid + Samba

Snapshots must be visible inside the SMB share path

For example, if your share is:

/mnt/cache/documents

Then snapshots must appear under:

/mnt/cache/documents/.snapshots/...

NOT:

/mnt/cache/.snapshots/documents/...

If they’re elsewhere, you must bind-mount them in.

Example: working Unraid Btrfs layout

Let’s assume your snapshot tool creates:

/mnt/cache/documents/.snapshots/
└── snap-2024-01-26_12-00
└── snap-2024-01-25_12-00

Each snapshot contains a full filesystem view of documents.

-snapshots plugin...

Correct shadow_copy2 config for Btrfs on Unraid

Add this to SMB Extras or per-share config:

[documents]
   path = /mnt/cache/documents
   read only = no

   vfs objects = shadow_copy2

   shadow:snapdir = .snapshots
   shadow:basedir = /mnt/cache/documents

   shadow:sort = desc
   shadow:localtime = yes

   shadow:format = snap-%Y-%m-%d_%H-%M

Key points

Option	Why it matters
shadow:snapdir	Relative path inside the share
shadow:basedir	REQUIRED on Unraid (non-standard layout)
shadow:format	Must match directory names exactly
shadow:localtime = yes	Windows expects local timestamps

If your snapshots live elsewhere (very common)

Example snapshot location:

/mnt/cache/.snapshots/documents/snap-2024-01-26_12-00

You must bind-mount them:

mkdir -p /mnt/cache/documents/.snapshots
mount --bind /mnt/cache/.snapshots/documents /mnt/cache/documents/.snapshots

Persist it (User Scripts plugin or /boot/config/go).

Testing before touching Windows

Run this on Unraid:

ls /mnt/cache/documents/.snapshots

If Samba can’t see snapshots here, Windows never will.

Then validate Samba parsing:

testparm -sv | grep shadow

---

Windows-side requirements (easy to miss)

• Must access via SMB share, not mapped drive shortcut

• Right-click file, not folder → Restore previous versions

• Works best on Windows Pro

• SMB3 required (default on Unraid)

Common Unraid gotchas (you’re probably hitting one)

❌ Snapshots created at filesystem root
❌ Snapshot names don’t match shadow:format
❌ Missing shadow:basedir
❌ Snapshots created on cache, share served from array
❌ Using plugins that auto-prune snapshots before Samba sees them

Bottom line

Unraid + Btrfs absolutely works with shadow_copy2, but:

• You must manually make snapshots visible inside the share

• You must match naming exactly

• You must bind-mount if snapshots live elsewhere

so lets use a common default folder that lives on uraid for docker appdata...

Goal

Expose Btrfs snapshots of /mnt/cache/appdata to Windows via Samba shadow_copy2 so Previous Versions works.

this will leverage teh extra parm smb share setting to use btrfs...

Sanity check (Btrfs)

Run this once:

stat -f -c %T /mnt/cache/appdata

Expected:

btrfs

If that matches, proceed.

Create the snapshot container inside the share

Snapshots must live inside the share path.

I currently have 0 snapshots...

Again, Snapshots must live inside the share path....

mkdir -p /mnt/cache/appdata/.snapshots
chmod 755 /mnt/cache/appdata/.snapshots

---

Then, Create a traditional Btrfs snapshot (read-only)

We’ll use a timestamp format that Samba parses cleanly:

snap-YYYY-MM-DD_HH-MM

Command

btrfs subvolume snapshot -r \
  /mnt/cache/appdata \
  /mnt/cache/appdata/.snapshots/snap-$(date +%Y-%m-%d_%H-%M)

*However gotchas ensure...

what’s going on, and it’s a very common Btrfs gotcha.

TL;DR: /mnt/cache/appdata is a regular directory, not a Btrfs subvolume.
Btrfs can only snapshot subvolumes, not plain directories.

Let’s fix this cleanly and safely.

---

Why this happens (important mental model)

Btrfs hierarchy looks like this:

Btrfs filesystem
└── subvolume (can be snapshotted)
    └── directories (CANNOT be snapshotted individually)

Right now:

/mnt/cache        ← Btrfs filesystem
└── appdata       ← normal directory 

❌

So this fails:

btrfs subvolume snapshot /mnt/cache/appdata ...

because appdata is not a subvolume.

btrfs subvolume create /mnt/cache/appdata

Two valid ways forward (pick ONE)

✅ Option A (RECOMMENDED): Convert appdata into a subvolume

This is the correct approach for snapshots + shadow copies.

⚠️ Option B: Snapshot the entire /mnt/cache subvolume

Works technically, but bad idea for Samba shadow copies and restores.

We’ll do Option A.

OPTION A — Convert appdata to a Btrfs subvolume (safe)

This does not delete data if done correctly.

---

1️⃣ Stop Docker / services using appdata

On Unraid/OMV/etc:

docker stop $(docker ps -q)

(Or stop containers via UI.)

---

2️⃣ Rename the existing directory

mv /mnt/cache/appdata /mnt/cache/appdata.old

Verify:

ls /mnt/cache

You should see:

appdata.old  swap  system

---

3️⃣ Create a real Btrfs subvolume

btrfs subvolume create /mnt/cache/appdata

Verify:

btrfs subvolume list /mnt/cache

You should now see appdata listed.

---

4️⃣ Copy data back (preserve permissions)

rsync -aHAX --numeric-ids /mnt/cache/appdata.old/ /mnt/cache/appdata/

Double-check:

ls /mnt/cache/appdata

---

5️⃣ Remove the old directory (ONLY after verification)

rm -rf /mnt/cache/appdata.old

---

6️⃣ Create snapshot directory inside the subvolume

mkdir -p /mnt/cache/appdata/.snapshots
chmod 755 /mnt/cache/appdata/.snapshots

---

###############################

Now create the snapshot (this will WORK)

btrfs subvolume snapshot -r \
  /mnt/cache/appdata \
  /mnt/cache/appdata/.snapshots/snap-$(date +%Y-%m-%d_%H-%M)

Verify:

ls /mnt/cache/appdata/.snapshots

Example output:

snap-2026-01-26_18-12

And confirm Btrfs sees it:

btrfs subvolume list /mnt/cache | grep appdata

You should see:

• appdata

• appdata/.snapshots/snap-...

THEN:
Samba config (unchanged, still correct)

[appdata]
   path = /mnt/cache/appdata
   browseable = yes
   read only = no

   vfs objects = shadow_copy2

   shadow:snapdir = .snapshots
   shadow:basedir = /mnt/cache/appdata

   shadow:format = snap-%Y-%m-%d_%H-%M
   shadow:sort = desc
   shadow:localtime = yes

the above replaces the samba share setting for appdata:

this requires turning off unraid web ui shares tab for appdata off as we will be making our own smb extra share setting

set to no and apply... extra is unable to repalce smb.conf sahre settings.
it either use the unraid web ui or the smb extra to defiune the share...

On 1/15/2026 at 3:55 PM, Ironthorne said:

3. SimonF Snapshots plugin

I want to be very clear:

I have huge respect for the work plugin authors do for the community.

This is not a complaint — just an observation of behavior on 7.2.2.

When I tried the plugin:

- The GUI hook for the Snapshots tab did not appear

- The SMB include file was not generated

- The cron integration conflicted with Unraid’s scheduler

- The plugin’s SMB injection mechanism didn’t seem to fire

Because of this, I uninstalled it to avoid further conflicts.

If the plugin is still the intended path on 7.x, I’d be very happy to reinstall it and configure it manually.

Hi, there is no integration into SMB with this plugin. Snapshots shows on the tools page, there is no tab across the menu bar. Not sure what issues you mean with cron as you define when you want something to run.

Please post anything on the support page. I have not activiely made any updates to this plugin as most people are now using ZFS. I would expect snapshots to be added to the product at some point in the future.

Any suggestions for options to add support to SMB settings I will raise a feature request to see if it can be added as a toggle/option to enable shadow copy.