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.

[homes]
        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[22266]: [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[22266]:   ../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.