If infected file is uploaded using smbclient it succeeds for the 1st time and fails for the 2nd time: $ smbclient //10.53.57.35/virusfilter -Upfilipen%fileserver -c "put infected.txt infected.upload.txt" putting file infected.txt as \infected.upload.txt (12.7 kb/s) (average 12.7 kb/s) $ smbclient //10.53.57.35/virusfilter -Upfilipen%fileserver -c "put infected.txt infected.upload.txt" NT_STATUS_ACCESS_DENIED opening remote file \infected.upload.txt This inconsistent( and thus confusing) behavior happens with the default smb.conf settings, which are: virusfilter:scan on open = yes virusfilter:scan on close = no Since the file 'infected.upload.txt' does not exist during the 1st call, it is not scanned at all. During the 2nd call we are trying to overwrite already existing 'infected.upload.txt' and virusfilter scan is performed resulting in NT_STATUS_ACCESS_DENIED. Even if we set in smb.conf: virusfilter:scan on close = yes virusfilter:block access on error = true virusfilter:scan error errno on close = EACCES The behavior is the same. The scan is actually performed on close, but it is ignored. With these two smb.conf options: virusfilter:infected file action = rename virusfilter:scan on close = yes The file is uploaded and immediately renamed from 'infected.upload.txt' to 'virusfilter.infected.txt.infected', which makes the 1st and 2nd call behave in the same way.