I suspect this is the correct behavior in this case. The MaxScanSize limit is not fatal, exactly. I believe it can be added when encountering a contained file which would exceed the scan size limit and then continue scanning the remaining files in case there are some smaller ones which wouldn't exceed the limit. Then when the MaxScanTime limit is reached, it adds that as well. Finally for reporting, it reports one of the alerts.
If you scan with the AllMatch feature enabled, it should report both... I think. Respectfully, Val Valerie Snyder (she/they) ClamAV Development Talos Cisco Systems, Inc. ________________________________ From: clamav-users <[email protected]> on behalf of Andrew C Aitchison via clamav-users <[email protected]> Sent: Tuesday, December 2, 2025 4:23 PM To: Paul Kosinski via clamav-users <[email protected]> Cc: Andrew C Aitchison <[email protected]> Subject: Re: [clamav-users] A MAJOR problem with "remote" scanning using ClamAV I was having a look at this this afternoon and hit MaxScanTime (which was set to two minutes) but still got: Heuristics.Limits.Exceeded.MaxScanSize FOUND ----------- SCAN SUMMARY ----------- Infected files: 1 Time: 96.369 sec (1 m 36 s) Start Date: 2025:12:02 21:14:34 End Date: 2025:12:02 21:16:11 - so the error may not match the limit actually hit ! This is Ubuntu questing/25.10 with the Ubuntu clamav packages. # clamdscan -V ClamAV 1.4.3/27838/Tue Dec 2 09:22:40 2025 On Tue, 2 Dec 2025, Paul Kosinski via clamav-users wrote: > Thanks! (And welcome back.) > > I never noticed that option in clamd.conf, nor had it occurred to me that > there might be such. > > Since I had previously been using clamd locally for scanning, I used > "--fdpass", which does not hit *that* limit, since only the commands are > streamed, not the data to be scanned. > > In the remote case, I only got "Broken Pipe" (TCP RST), rather that any error > message, so it looked like a lower level problem. If clamd had given an > explicit response, it probably would have been obvious. > > I guess it would work for me to set StreamMaxLength to 2G-1, since the new > machine running clamd has 32G of RAM (even though it is far from "high end"). > > Paul > > -------------------------------- > > On Mon, 1 Dec 2025 22:40:19 +0000 > "Val Snyder (valsnyde)" <[email protected]> wrote: > >> Hi Paul, >> >> Sorry for the long delay. I have been away for a couple of weeks. >> >> ClamD has a StreamMaxLength setting with a default value of 100M which is >> close to the 105 MB value you encountered. >> I suspect you're running into this limit when streaming files to be scanned. >> If you want to send a bigger file you can increase this to match >> MaxFileSize . >> >> E.g. set both of these in clamd.conf: >> >> MaxFileSize 2000M >> StreamMaxLength 2000M >> >> Respectfully, >> Val >> >> Valerie Snyder (she/they) >> ClamAV Development >> Talos >> Cisco Systems, Inc. >> >> ________________________________ >> From: Paul Kosinski <[email protected]> >> Sent: Thursday, November 13, 2025 2:01 PM >> To: [email protected] <[email protected]>; Val >> Snyder (micasnyd) <[email protected]> >> Cc: Akshit Jain <[email protected]>; Kris Deugau <[email protected]> >> Subject: A MAJOR problem with "remote" scanning using ClamAV >> >> Several people have noted that using ClamAV remotely (e.g., via TCP) does >> not perform scanning *while* the file/data is being transferred, but only >> after all the data has been transferred. This makes sense, given the way >> some signatures work (e.g., those that depend on total hashes). >> >> But there is a much worse problem that I have observed: sometimes it *never* >> scans the file/data at all! This happens when there is "too much" data to be >> scanned. By too much, I don't mean the well known 32-bit size limit, I mean >> sizes that can easily be scanned locally, either by a direct (but slow) call >> of clamscan, or a more efficient call of clamdscan with the "--fdpass" >> option (assuming clamd is running locally). >> >> Since I am temporarily using ClamAV on a small but powerful new computer and >> remotely scanning email that way, I also have to use it to scan things like >> downloaded files. I have had no trouble with email, but some downloaded >> files abort with "Broken Pipe". Monitoring this behavior with Tshark, I >> observed that the remote clamd started sending RST packets after about 105 >> MB of a 170 MB file. >> >> I haven't studied the source code for either clamd or clamdscan, but I >> suspect a buffer allocation problem, since TCP has no such inherent limit. >> (And my new "small" computer has 32 GB of RAM with a recent AMD Ryzen CPU, >> and doesn't currently have any real load beyond ClamAV.) > _______________________________________________ > > Manage your clamav-users mailing list subscription / unsubscribe: > https://lists.clamav.net/mailman/listinfo/clamav-users > > > Help us build a comprehensive ClamAV guide: > https://github.com/Cisco-Talos/clamav-documentation > > https://docs.clamav.net/#mailing-lists-and-chat > -- Andrew C. Aitchison Kendal, UK [email protected] _______________________________________________ Manage your clamav-users mailing list subscription / unsubscribe: https://lists.clamav.net/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/Cisco-Talos/clamav-documentation https://docs.clamav.net/#mailing-lists-and-chat
_______________________________________________ Manage your clamav-users mailing list subscription / unsubscribe: https://lists.clamav.net/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/Cisco-Talos/clamav-documentation https://docs.clamav.net/#mailing-lists-and-chat
