Comment 4 for bug 581614

I have the same issue - well, it looks like the same issue. I don't think its whether hard links are supported on CIFS or not though. Would be interesting if you could try this fix.

Using CIFS the incremental backups aren't incremental, but they are incremental when using a local target filesystem. I started to wonder about this when all my test backups were taking the same amount of time :) I confirmed it by looking at the inode numbers of the various snapshots - different inode numbers for the same files.

It looks like this is due to the permissions on the snapshot heirarchy being set to remove write permission. cp -al seems to work ok on a local filesystem but when using a CIFS mounted filesystem the cp fails because it can't write subdirectories (it must be applying permissions at the time the directories are created unlike local filesystems). So since the cp failed, rsync just creates all the files as if they were new.

I've attached a patched 0.9.99.37 snapshot.py file that appears to fix the issue (copy_snapshot function not modified since it doesn't appear to be called from anywhere. The find command added as a Debian patch was removed since files should already be u+wx before the copy now):

Diff of snapshots.py with 0.9.99.37
62c962,964
< cmd = "cp -al \"%s\"* \"%s\"" % ( self.get_snapshot_path_to( prev_snapshot_id ), new_snapshot_path_to )
---
> old_snapshot_path_to = self.get_snapshot_path_to( prev_snapshot_id )
> self._execute( "find \"%s\" -type d -exec chmod u+wx {} \\;" % old_snapshot_path_to ) #CIFS patch
> cmd = "cp -al \"%s\"* \"%s\"" % ( old_snapshot_path_to, new_snapshot_path_to )
964c966
< self._execute( "find \"%s\" -type d -exec chmod u+wx {} \\;" % new_snapshot_path ) #Debian patch
---
> self._execute( "find \"%s\" -type d -exec chmod u-w {} \\;" % old_snapshot_path_to ) #CIFS patch

Note that there still seems to be an issue with being unable to change ownership of the files on a CIFS filesystem using cp at least for me - this does not stop the copy but just generates needless warnings from chmod saying it can't set ownership. I'll raise this in a separate bug report