This bug was raised in Debian, where one of our users has trouble with BackupPC since his system was upgraded and samba went from  3.5.6 to 3.6.1 (and the problem persists with 3.6.{3-5}).

He tries to backup Windows clients with the BackupPC utility that itself uses smblclient's tarmode.

Since the upgrade, backups fail because the "System Volume Information" directory that exists on Windows clients cannot be listed. This, even if the directory is explicitely excluded.

See his commenbts:

> The bug can be reproduced with smbclient 3.6.4-1, and I think with
> 3.6.3. I am not very familiar how exactly backuppc proceeds, but this is
> the command it uses for backup:
> 
> $smbClientPath \\$host\$shareName $I_option -U $userName -E -d 1 -c
> tarmode\ full -Tc$X_option - $fileList
> 
> This is the description of all variables
> 
>    $smbClientPath   path of smbclient
> <http://bnsa864/backuppc/index.cgi?action=view&type=docs#_conf_smbclientpath_>
>    $host            host to backup/restore
>    $shareName       share name
>    $userName        user name
>    $fileList        list of files to backup (based on exclude/include)
>    $I_option        optional -I option to smbclient
>    $X_option        exclude option (if $fileList is an exclude list)
> 
> 
> I have tested the command manually, and it stops when trying to list
> System Volume Information on the remote share with
> the following errors:
> 
>     directory \System Volume Information\
>     NT_STATUS_ACCESS_DENIED listing \System Volume Information\*
>     NT_STATUS_ACCESS_DENIED listing \\*   (it stops here)
> 
> And this is the output with smbclient 3.5.6
> 
>     directory \System Volume Information\
>     NT_STATUS_ACCESS_DENIED listing \System Volume Information\*
> 
> After that the backup continues normally.

From my understanding, what's happening here is that smbclient tardmode insists on listing the content of a directory even if that directory is explicitely excluded, which was not happening with 3.5 versions