Bug 753531 - Samba 3.6.1-74 incompatible with BackupPC 3.2.1-6 for Win7 smb backups
Samba 3.6.1-74 incompatible with BackupPC 3.2.1-6 for Win7 smb backups
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: samba (Show other bugs)
16
All Linux
unspecified Severity low
: ---
: ---
Assigned To: Guenther Deschner
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-11-13 01:32 EST by Brent
Modified: 2013-02-13 09:26 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-13 09:26:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Brent 2011-11-13 01:32:34 EST
Description of problem:


Version-Release number of selected component (if applicable): 

samba-common               i686      1:3.6.1-74.fc16
BackupPC-3.2.1-6.fc16.i686 


How reproducible:

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.
  
Actual results:

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 \\*)


Expected results:

The backup should complete normally.

Additional info:

Removing samba 3.6.1.74 packages and building new RPMs from the samba 3.5.11-71 SRPM fixes the backup issue. 

samba-common-3.5.11-71.fc16.1.i686
samba-winbind-clients-3.5.11-71.fc16.1.i686
samba-3.5.11-71.fc16.1.i686
samba-client-3.5.11-71.fc16.1.i686
samba-winbind-3.5.11-71.fc16.1.i686
Comment 1 Johnny Hughes 2012-02-04 10:15:38 EST
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.
Comment 2 Johnny Hughes 2012-02-04 10:18:15 EST
There is a similar bug report for Debian here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653207
Comment 3 Brent 2012-04-16 14:28:15 EDT
Bug still exists in samba 3.6.4-82.fc16.  

Further information:


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.
Comment 4 Brad Morgan 2012-06-14 16:30:14 EDT
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
Comment 5 Fedora End Of Life 2013-01-16 08:35:25 EST
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 6 Fedora End Of Life 2013-02-13 09:26:14 EST
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.

Note You need to log in before you can comment on or make changes to this bug.