[clamav-users] clamav "Can't unlink file ERROR"

[An Schall]

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 <clamav-users at lists.clamav.net>:
>
> 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
> clamav-users at lists.clamav.net
> 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