Full backup may not back up all files on Samba share yet report success

[Mikko Kortelainen]

Due to a regression in smbclient apparently starting from version 3.6, not all files may be backed up by a BackupPC full backup. Yet BackupPC reports the backup as successful.

The first NT_STATUS_ACCESS_VIOLATION error in a particular directory stops the backup for the given directory, so that subsequent files and subdirectories in that directory are not backed up. The processing will continue with the next same level or upper level directory. Depending on the order, some files and subdirectories may not be backed up.

So for example, if a backup of a C$ share on a Windows host processes files in alphabetical order, and C$/pagefile.sys gives the NT_STATUS_SHARING_VIOLATION error, the C$/Program Files, C$/Users and C$/Windows among other directories will not be backed up.

The backup is nevertheless shown as a full backup and not a partial one in the BackupPC user interface. Looking at the error log, the user can see NT_STATUS_SHARING_VIOLATION errors, but there is no indication that the rest of the directory was skipped because of this. And a typical Windows host will have a number of those errors just because of files that are in use. So it is not immediately obvious that a potentially large number of files were skipped. Only by browsing the resulting backup, or perhaps comparing backup and source sizes, can the user notice missing files.

A subsequent incremental backup may actually back up more files, as it may exclude some of the ones with those errors. I actually came across this bug by seeing incrementals back up much more files than full backups. Incrementals get deleted after a week in the default configuration, leaving partial full backups.

It is quite alarming to realize this bug may affect all users with the default packages and default configuration who are backing up Samba shares with locked files - practically any Windows target.

This is probably related to this Samba bug:

https://bugzilla.samba.org/show_bug.cgi?id=10605

That bug is tagged to Samba 3.6, but I have seen the same behaviour with Samba 4.1.6 in Trusty. The best way to see this is to run the backup command from the command line and see it die prematurely after the first error in the root of the share.

A workaround to this issue is to downgrade smbclient to version 3.5.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.