Dear Ged, thanks for your elaborate answer. We were able to identify the underlying root cause. The machine was scanning a file on a global filesystem. This filesystem can be accessed by other machines as well. One of the other machines with access to the filesystem had another anti-virus solution that was interfering with the operations of clamAV.
Thanks again, An Am Di., 17. Mai 2022 um 13:16 Uhr schrieb G.W. Haywood via clamav-users <[email protected]>: > > Hi there, > > On Tue, 17 May 2022, An Schall via clamav-users wrote: > > > we are trying to get clamscan / clamdscan functional on a RHEL with > > GPFS as a filesystem. > > Is the operating system also on GPFS or is this a separate filesystem? > > Do you have any examples of clamdscan actually being able to delete a > test file on this system, or can it never do that? > > > We are using clamAV 0.104.2. On a different test machine everything > > works like a charm. > > Does the system which appears to be working as you expect also use the > GPFS filesystem in the same way? > > > However, on this specific RHEL machine, we get the following errors: > > # clamdscan -v --config-file=/etc/clamav/clamd.conf --multiscan \ > > Do you see the same problem using 'clamscan' instead of 'clamdscan'? > > > --fdpass ./ /global/mmds/test/platform/antivirus/antivirus/yes\ > > -virus/dissemination-benchmark-file-set-plus-virus.zip: Can't \ > > unlink file ERROR > > ... > > Generally speaking it is dangerous to configure ClamAV utilities to > unlink files. If you get it wrong, you can easily trash a perfectly > good system. It's possible for ClamAV erroneously to flag something > in one of your system files - what we call a 'false positive'. These > can happen at more or less any time without warning because signatures > in the official signature databases are updated at least twice per day > and other signatures (if you use them) may be updated at any time. If > you configure ClamAV to delete suspicious files, you are trusting that > third parties won't make any mistakes that could ruin your whole week. > In any case I wonder if you can be sufficiently confident that you'll > never get it wrong yourself. Speaking for myself, I'd never be sure > and I'd never let ClamAV delete anything except its own tempfiles. Of > course you might be happy to delete files in a non-system partition if > you can be sure that's the limit of the foreseeable damage. > > > ... > > What is the underlying reason of this error message? > > The underlying reason could be that clamdscan does not have permission to > unlink the file. AppArmor and SELinux often give troubles like this. In > this case that might not be the explanation. You tell us that libclamav > > > "reports something about ""cli_unlink" failure no such file or directory". > > The exact error message is usually more helpful than "something about" > but this looks fairly straightforward. The clue is in the part which > says "no such file or directory". It seems to be saying that you are > asking libclamav to unlink a file which it can't find. One thing you > might want to check is that the path which libclamav is complaining > about is what you would expect. This looks suspicious to me: > > /global/mmds/test/platform/antivirus/antivirus/... > > Do you really have a directory 'antivirus' which contains a directory > called 'antivirus'? It isn't impossible but when mounting filesystems > it's the sort of mistake that can happen. In addition there are some > not-so-subtle differences between 'unlink' and 'remove' which might be > relevant especially if you're using unusual filesystems but I wouldn't > start digging that hole just yet. > > > Here is the clamd.conf: > > ... > > The output of the command > > clamconf -n > > is often helpful. > > I don't know why libclamav couldn't find the file that it was trying > to delete. Perhaps it really wasn't there. Perhaps there's something > funky going on in the filesystem. Perhaps another process deleted the > file (or renamed it, moved it or part of the path, or whatever) before > libclamav tried. You need to investigate. I see you're using verbose > logging, detailed logs might help if you can place them e.g. on a file > sharing service for us to look at. > > Read the man page for clamdscan. Do be aware that although clamdscan > accepts many clamd options, it ignores most of them. The actual scan > parameters are determined by the clamd configuration in effect at the > time that clamd was started. > > Have you checked for possible ClamAV issues in the Github repository? > I don't see anything there which looks likely to explain your problem > and I haven't seen similar complaints on the list, but I might easily > have missed something. > > -- > > 73, > Ged. > > _______________________________________________ > > clamav-users mailing list > [email protected] > https://lists.clamav.net/mailman/listinfo/clamav-users > > > Help us build a comprehensive ClamAV guide: > https://github.com/vrtadmin/clamav-faq > > http://www.clamav.net/contact.html#ml _______________________________________________ clamav-users mailing list [email protected] https://lists.clamav.net/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
