Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 14 replies
  • Subscribers 10 subscribers
  • Views 18448 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

talpa-deny errors preventing backups on ubuntu 20.04

pastim

I run sophos free SAV: 9.16.2, Engine: 3.79.0, Data: 5.77 , with talpa . Sophos Anti-Virus is active and on-access scanning is running

I use 7z to backup my files on ubuntu 20.04. Some of these files are from wine, and get talpa-deny errors in the system log, causing the backup to report timeouts, lock up and then have to be stopped.  However, I don't get virus alerts for these talpa-deny events.

An example from the syslog (my directory being replaced by .....) is:

kernel: [ 5994.994356] talpa-deny: Timeout occurred while opening ......../.wine/drive_c/windows/syswow64/mmdevldr.vxd on behalf of process 7z[7429/7429] owned by 1000(1000)/1000(1000) <62>

How can I
a) detect this better than just getting a syslog error
b) prevent it from happening



This thread was automatically locked due to age.

Top Replies

  • in reply to Shweta +1 verified

    Hello Shweta and pastim,

    unfortunately this article, while correct at the time of writing, is improper and at least the Overview part should be rewritten.

    It mentions and links to the Free Tools page but the SAV for Linux section has since been removed.

    It's not stated that the stand-alone installer is only available with one of the on-premise managed product licenses. Furthermore it should note that this applies only to existing licenses as these products are no longer on sale.

    @pastim:
    You probably know I'm not Sophos so this is my guess only. As to a Linux Home version like the ones for Windows and macOS. For one thing SAV for Linux lacks a GUI and doesn't have the look and feel of a typical "home" product. A quite different aspect is that there is no real desktop/server distinction on Linux. AFAIK Central (the business product line) considers any Linux endpoint to be a server - with the associated license fees.
    Perhaps insufficient ROI is expected from developing a home/desktop desktop branch that is given away for free or licensed at "home" rates.

    Last but not least the talpa-deny. You enquired about it already four years ago, didn't you? Guess the scanner doesn't report these errors as they are something that "shouldn't happen" and apparently they affect both the scanner and the process accessing the file.
    You could perhaps exclude the path(s) from on-access scanning while the backup is running.

    Christian

    Jump to answer
  • 0 in reply to pastim

    Hello pastim,

    it seems to prevent
    IMO neither deliberately nor negligently even though it is reproducible.

    The actual culprit is complexity and as said perfectly legitimate actions can nevertheless result in conflicts you can handle only by "graceful errors". I'll try to give a hopefully simple (and simplified) example that things can inherently go wrong.

    Sparse files: You write an application that maintains a table of 1k blocks. You request, say, 1k of these blocks. The file system has enough space available you get the space. For whatever reason you start with the last block. The underlying routines write one 1k block and when you close the file only one block is physically allocated. If you open the file and read it with "high-level" calls sequentially nothing is actually read from disk until you get to the last block. For all others you get a buffer filled with whatever is considered as empty. For your application the file seems to be 1M in size. Now you start writing more blocks within those 1M but suddenly you get an out of space. Huh? Your application might not be prepared for this - you had already 1M and you just used space from these 1M. Only the physical file system no longer had this space. This is a risk in the concept of sparse files. The why use sparse files? Tables indexed with hashes are mostly empty. If you really allocate them you'd waste lots of space. Now you could add logic that keeps the table dense. This adds extra processing because the file system must perform a similar task to find physical space. This is a compromise that works most of the time but not always.
    What actually happens in a file system is much more complex and there is more than one way to do certain things. Under certain circumstances conflicts arise that are not really someone's fault. I haven't mentioned the complexity process scheduling, asynchronous operation and all that there is. There are always situations you can only work around, combinations of legitimate actions that conflict.

    Christian

  • 0 in reply to QC

    Hmm.  Well I find all that a little hard to believe. In all my 47 years using and programming computers I've not encountered similar issues except with sophos and talpa. All I am doing is copying a file from one place to another. 

    The only files that seem to have problems are .wine files.  I wonder whether sophos is getting tangled up with what appear to be windows files, but are actually on a linux system.

    You may, of course be perfectly correct, but it's pretty weird nonetheless.


  • 0 in reply to pastim

    Hello pastim,

    you must have been lucky [;)]. A little less than 47 years and it depends on what you call similar but I can't say I haven't encountered "unfortunate interactions".

    All I am doing is copying a file [...] problems [with] .wine files
    using the Linux port of 7z    ? Or also when using the coreutils cp? 

    Christian 

  • 0 in reply to QC

    With 7z.

    Given that Sophos in their wisdom (?) may stop support before 2023 (it's not 100% clear) I'm now contemplating whether to go back to clamav (which I used several years ago), of pay for something like eset.