Title: S
### Environment
- OpenMediaVault 8.3.1-2 (Synchrony)
- Debian 13.1 (Trixie), kernel 6.12.90+deb13.1-amd64
- openmediavault-zfs plugin (version: 8.1.1)
- ZFS pool "work": mirror (2x SATA HDD), ashift=12, compression=off
- Nested datasets created via `zfs create`: work/personal-storage/ben
### Summary
When a Shared Folder's Filesystem+Relative-Path combination resolves into the mountpoint of a nested (child) ZFS dataset — rather than a plain subdirectory of the referenced Filesystem's own mountpoint — the Shared Folder's Privileges/ACL settings appear to save successfully in the UI but are never actually written to disk. SMB write access for the assigned user fails, while read/browse access still works because the directory retains its ZFS-created default permissions (root:root, 0755).
### Steps to reproduce
1. Create a ZFS pool "work" (mirror) via Storage → ZFS → Pools.
2. Create a nested child dataset via CLI: `zfs create work/personal-storage/ben`.
3. Storage → Shared Folders → Add: the "Filesystem" dropdown only offers the pool root ("work") — no child datasets are selectable (related: #1070).
4. Create a Shared Folder with Filesystem = "work", Relative Path = "personal-storage/ben". It is created successfully; the listed Absolute Path correctly shows /work/personal-storage/ben, status "Available".
5. Open this Shared Folder's Privileges/ACL, assign user "ben" = Read/Write, Save, apply pending changes.
6. On the server: `getfacl /work/personal-storage/ben`.
### Expected behavior
Directory shows an ACL entry `user:ben:rwx`; the SMB share built on this Shared Folder allows ben to write.
### Actual behavior
`getfacl` shows only the three default POSIX entries, no user-specific entry; owner/group stay root:root, mode 0755 — regardless of how many times the Privileges dialog is edited, saved, and applied. SMB write fails for ben from an actual client (tested from both macOS and Windows) even though the SMB share's own per-user permission list correctly shows the target user as Read/Write and "read only" unset.
Manually running `setfacl -m u:ben:rwx /work/personal-storage/ben` on the server immediately fixes SMB write access for that user, confirming the export path itself is correct and only the ACL-deployment step fails to reach it.
Reproduced identically for four separate Shared Folders, all following the same pattern (Filesystem="work", relative path into a nested child dataset).
### Workaround
Set ACLs directly via `setfacl` over SSH on the real absolute path.
