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
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: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653207
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.
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.