FSRVP with Snapper problem

Teng-Feng Yang shinrairis at gmail.com
Fri Jun 14 03:16:06 MDT 2013


Hi David,

Thanks for your quick reply.
I follow your advice to put both "Administrator" (The AD admin
account) and "FSRVPCLIENT$" (The AD machine account) into snapper
config file.
(I cannot set ALLOW_GROUPS to "DOM\Backup Operators", because there is
a space between "Backup" and "Operators".)
However, it's still not working as expected, and the snapper log shows
that snapper cannot find the uid of both "Administrator" and
"FSRVPCLIENT$".
I setup the AD DC based on this HOWTO on SambaWiki
http://wiki.samba.org/index.php/Samba_AD_DC_HOWTO
Did I miss anything in setting up AD DC?

I dig a little deeper into the samba log and find out that the
snapshot creation process failed when samba received
FSS_ISPATHSUPPORTED and try to connect to system DBUS.
It looks like the DBUS library block it from connecting to system bus,
and FSS_ISPATHSUPPORTED is never passed to snapperd.
(Based on the output of "sudo ps ax", snapperd is not brought up by
vfs_snapper module)

There is something interesting that I accidentally find out if I
connect to the storage server with rpcclient and call "fss_is_path_sup
<share path>" first, I will be able to create snapshots with
diskshadow.exe on WIndows.
I had reproduced this behavior for a couple of times, and it works everytime.
If I skip this step, the snapshot creation will fail as described above.

Any help would be grateful!

Dennis



2013/6/13 David Disseldorp <ddiss at suse.de>:
> 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



-- 
Teng Feng Yang
Research Assistant of Director. P.C. Yew
Parallel Processing Laboratory
Institute of Information Science
Academia Sinica, Taiwan
Tel: 886-2-27883799#1676
E-mail:shinrairis at iis.sinica.edu.tw


More information about the samba-technical mailing list