Red Hat Bugzilla – Bug 753531
Samba 3.6.1-74 incompatible with BackupPC 3.2.1-6 for Win7 smb backups
Last modified: 2013-02-13 09:26:14 EST
Description of problem:
Version-Release number of selected component (if applicable):
samba-common i686 1:3.6.1-74.fc16
Try to initiate a smb method backup of a Windows 7 client and it will error out when it reaches a Windows junction point (windows-ish sym link). I suspect the latest samba throws a different error type when it encounters this type of directory/file and aborts the backups. Even if you specifically exclude these junction points, the backup process will still error out. Reverting sambe to a 3.5 release fixes the backuppc issue with samba 3.6 installed.
Steps to Reproduce:
1. Install backuppc on a linx box
2. Configure it to backup a Windows 7 machine using SMB as the xfer mode.
3. Backups will fail
4. If they show as complete, there will be no data in the backup.
Log file for the client desktop will have the following logged:
2011-11-11 00:03:11 Backup failed on win7-desktop (NT_STATUS_ACCESS_DENIED listing \\*)
The backup should complete normally.
Removing samba 188.8.131.52 packages and building new RPMs from the samba 3.5.11-71 SRPM fixes the backup issue.
I can verify that the same thing happens with samba 3.6.3-4 RPMs from enterprisesamba.org on RHEL5.7 when trying to use the EPEL version of backuppc (3.2.1-6.el5).
The issue seems to be smbclient and the use of a * for file listing.
If I shift back to the samba 3.5.12-44 from enterprisesamba.org, everything works OK.
There is a similar bug report for Debian here:
Bug still exists in samba 3.6.4-82.fc16.
smbclient appears to hit Windows 7 junction points (C:\Documents and Settings, for example) and will throw an error that BackupPC interprets as a critical failure and then exists. BackupPC will show a partial backup, but in reality there are no useful files that are backed up.
Further, using BackupPC to backup the local linux box (using smb protocol) will result in smbd taking 100% CPU and then results in BackupPC timing out. When BackupPC retries an hour later, it will run another smbd process to 100%. I've seen 4 smbd processes taking 100% cpu, running the load up to 5.0+.
The fix for me:
replace smbclient included in samba-client-3.6.4-82.fc16.i686.rpm with smbclient Version 3.5.12-72.fc16.
Same solution for the smbd 100% cpu usage. Replace /usr/sbin/smbd with Version 3.5.12-72.fc16.
It seems the smbd 100% bug is when the backups hit special files (like sockets) when using smbclient to try to backup the file. The same issue probably occurs when backing up file in /proc.
I believe the following from http://www.samba.org/samba/history/samba-3.6.0.html may be relevant.
Changed security defaults
Samba 3.6 has adopted a number of improved security defaults that will
impact on existing users of Samba.
client ntlmv2 auth = yes
client use spnego principal = no
send spnego principal = no
The impact of 'client ntlmv2 auth = yes' is that by default we will not
use NTLM authentication as a client. This applies to the Samba client
tools such as smbclient and winbind, but does not change the separately
released in-kernel CIFS client. To re-enable the poorer NTLM encryption
set '--option=clientusentlmv2auth=no' on your smbclient command line, or
set 'client ntlmv2 auth = no' in your smb.conf
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '16'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 16's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 16 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" and open it against that version of Fedora.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.