FSRVP with Snapper problem

[David Disseldorp]

Hi Dennis,

On Thu, 13 Jun 2013 19:49:30 +0800
Teng-Feng Yang <shinrairis at gmail.com> wrote:

> Hi,
> 
> I checkout the source code from git://git.samba.org/ddiss/samba
> async_fsrvp_srv_wip_xp2013 to try the remote snapshot feature.

I appreciate your efforts in testing this implementation. I look forward
to getting this code-base into a state where it's suitable for master.

> I setup an ubuntu workstation as the storage server and AD DC and use
> the diskshadow.exe utility provided by a Windows Server 2012 which
> joins the AD.
> It works perfectly when I share a btrfs volume via samba with btrfs
> and shadow_copy vfs modules hooked on it.
> However, when I use the similar approach to share a dm-thin volume
> with snapper and gmt_token vfs modules, I cannot take snapshot from
> Windows Server remotely.
> In the meantime, I have also tried to take remote snapshots via
> rpcclient, and it works like a charm.
> I trace the log dumped by samba, and find something that might be the problem.
> It looks like when I try to take snapshot from diskshadow.exe, the
> samba will verify the access right of both <AD account> and < Computer
> Name of Windows server >.
> Although I have put both <AD account> and <Windows computer name> into
> "Backup Operators" AD group, it turns out that the dbus connection
> will fail(timeout) when vfs_snapper calls snapper_dbus_conn() in
> snapper_snap_check_path().
> The error message in log file is: "/usr/local/samba/sbin/smbd: dbus
> connection error: Did not receive a reply. Possible causes include:
> the remote application did not send a reply, the message bus security
> policy blocked the reply, the reply timeout expired, or the network
> connection was broken."

I expect you're experiencing the (vfs_)snapper UID detection bug
discussed at SambaXP. As you've described, the diskshadow.exe FSRVP
client on Windows Server 2012 first connects as the AD machine account
to check whether the remote share supports shadow copies. It then
proceeds to connect as the logged-in user to issue the snapshot creation
request.

The vfs_snapper->snapperd D-Bus connection does not handle the UID
change, and processes the snapshot creation request as the machine
account instead of the logged-in user. To work around this issue, the
machine account and the logged-in user must be added to the ALLOW_USERS
entry in the snapper config - normally only the logged-in user would be
required. It should also work if you add "DOM\Backup Operators" to the
ALLOW_GROUPS entry. snapperd should be killed after the change, to
ensure that it picks up the new configuration.

Cheers, David