I have a 'homes' share set up for users connecting in to an RDS farm so their "My Documents" follows them.
The data is stored in a zfs dataset with snapshots enabled.
comment = User Profiles
path = /tank/userprofiles/%S
valid users = %S
root preexec = /usr/local/bin/smbmkzfs.sh %S
vfs objects = shadow_copy2
shadow: snapdir = .zfs/snapshot
shadow: sort = desc
shadow: format = zfs-auto-snap_frequent-%F-%H%M
When a new user is added, I don't want to have to remember to create the underlying /tank/userprofiles/<username> folder, so I have a 'root preexec' that runs 'zfs create tank/userprofiles/<username>'.
When I have the shadow_copy2 VFS object enabled, I get the following in my syslog, and the 'root preexec' is never run:
Sep 18 11:42:29 kvm1 smbd: [2015/09/18 11:42:29.492456, 0] ../source3/modules/vfs_shadow_copy2.c:1838(shadow_copy2_connect)
Sep 18 11:42:29 kvm1 smbd: ../source3/modules/vfs_shadow_copy2.c:1838: shadow_copy2_find_mount_point failed: No such file or directory
My guess is that the shadow_copy2 object is looking for /tank/userprofiles/<username> *before* the 'root preexec' is run, and when it bombs out, the new user can't connect.
If the /tank/userprofiles/<username> folder *already* exists and shadow_copy2 is enabled, there are no problems with users connecting.
If the /tank/userprofiles/<username> folder *does not* exist and shadow_copy2 is enabled, they get the error logged above, the folder is never created, and the user can not connect.
If I remove the shadow_copy2 VFS object, users with existing folders can still connect without problems, but users *without* existing folders can now connect...but unfortunately without the ability to self-restore files.