The logrotate script for samba-2.0.7-4 (for example) specifies files /var/log/samba/log.*. This causes already-rotated files such as log.nmb.1 to be rotated to log.nmb.1.1, etc. Each rotation, every file in the directory gets rotated and an additional .1 is appended to its name. A quick and dirty workaround is to specify explicitly the name of every file to be rotated. In samba, however, these file names are not known a priori--there is a name for every SMB machine on the network. The fix that is needed is either for logrotate to be aware of what files are already rotated and ignore them even in the presence of wild cards or to give users better ways to specify what files are the original logs and what ones are rotated. (cf. also bug report 6998)
This is not a problem if you require all log files you rotate end with an extension like .log Logrotate can create files with .gz and .1 .2 .3 ... extensions and no exponential expansion will be performed. The problem wit Samba was specific format of log files format.
This should actually be a samba bug because the logrotate file comes with the samba rpm. The original rpm from samba.org doesnt have this problem.
This is already fixed in the latest samba packages.
IMHO, a nicer solution would be for logrotate itself to avoid rotating files wilh suffixes .1, .2, .gz, .z, .Z, or whatever. For example, the junkbuster package creates log files like /var/log/junkbuster/junkbuster. Here, there is no wildcard spec in logrotate that will stop the proliferation of rotated files. Yes, you can argue that that's a junkbuster bug (and I have made that point to the packager, but it's still not been fixed), but I think it would be less irritating to fix the problem once and for all in logrotate. Then we don't need to rely on the kindness of strangers to keep things running smoothly.
I am using RH 6.2 with the latest samba-2.0.7-4 and I am still experiencing this behaviour. Which "latest samba packages" fix this problem?
This bug can cause logrotate to create so many files that the filesystem # of files limit will be reached. That can create a number of really nasty problems, so it should warrant an Errata release. I filed a bug #28919 asking for an Errata.