Bug 11524 - shadow_copy2 VFS object and root preexec: shadow_copy2_find_mount_point failed: No such file or directory
Summary: shadow_copy2 VFS object and root preexec: shadow_copy2_find_mount_point faile...
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: VFS Modules (show other bugs)
Version: 4.1.17
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-09-18 18:55 UTC by Aaron C. de Bruyn
Modified: 2015-09-18 18:55 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aaron C. de Bruyn 2015-09-18 18:55:23 UTC
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.