talpa-deny errors preventing backups on ubuntu 20.04

Hi pastim 

Free SAV for Linux and its support has been retired (For more info please see: https://support.sophos.com/support/s/article/KB-000034795?language=en_US). I would request you to kindly upgrade to the standalone Linux/Unix endpoint or Central/Enterprise Console managed endpoint.

That's an unexpected blow.

I've had a look at your home page and can't find the product you mention by that name.  I assume you mean Intercept X.

Is there no product that I can install on a linux laptop, one desktop and one server?  I'm not averse to paying a bit, but certainly don't want to start adding extra boxes to my network, not least because my laptop isn't always at home.  Could you please advise whether Sophos still provide products for this type of use or not.  

Hi pastim 

Unfortunately, the free version of Sophos Antivirus for Linux has been discontinued. You can install the standalone version of the Sophos Anti-Virus as mentioned in this article. 

Thanks, but I'm afraid this is as clear as mud to me.  The 'free' version is, as far as I can tell, the same as the standalone version, just without support, and always has been.  The SAV software is, according to the article you referred me to, reaching EOL in 2023.  Before then I assume I will still get updates in the normal way.  Is that not right?

There are other threads on this topic, such as https://community.sophos.com/products/free-antivirus-tools-for-desktops/f/sophos-free-tools/121788/sav-for-linux-free-edition-is-discontinued

I would ask SOPHOS to come out and be really clear what they intend to sell and support for standalone use on Linux.

There is a free Windows/MAC version, and a free Android version.  I don't see any reference to EOL for them.  What's with linux?

If SOPHOS really don't want to work with non-business standalone users maybe they should just say so clearly so we can all go off and find some other free or paid version.

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

Christian, 

Thanks very much.  From what you say I gather there will be no stand alone Sophos for Linux at all (paid or free) once EOL is reached in 2023, so I'll need to look fo something else in the next couple of years.  No rush.

I have completely forgotten reporting on talpa-deny in the past - my memory is pretty bad at the best of times.  I'll see what I can do to exclude the directories from access scanning during backups.

I'm not wholly rejecting Christian's answer to my question.  However, un-alerted talpa-deny errors seem to me to be bugs, and so a report of this nature should really stand until the bug is fixed.

However, since there's never been any support for the free version, and presumably even less now it's unavailable, that isn't going to help me much.

So the technique to avoid the issue will have to suffice.  Thanks.

I wonder how answers get marked as 'the answer'.  By computer?  By moderator?  I might have thought someone would expect the originator of the thread to be responsible for doing that. Naive of me.

Hi pastim 

I can understand your situation and I have marked QC's answer as a verified answer. I'll reach out to the concerned team to get the KB article updated with more information. I thank you for your cooperation and understanding. 

Hello pastim,

un-alerted talpa-deny errors seem to me to be bugs
I'm a Talpa-ἰδιώτης (if you're looking for an expert DouglasLeeder is one), never encountered such errors and thus can only conjecture what they signify. If I had to guess I'd say an unexpected timeout resulted in the decision to deny access. Unexpected in the sense that preceding operations on the file succeeded and thus a reopen should not time out. But I might be completely wrong.
I don't get virus alerts for these talpa-deny events
you mean there's no message in the savlog? Talpa is not SAV, I don't think that it's even aware that a savlog exists. And if the scanner is already done with the file it probably no longer communicates with Talpa.

I'm not sure if there is what could be called a bug (some things simply don't go together) and if, where it is. If it's not in Talpa or SAV then Sophos can't fix it.

marked as 'the answer'.  By computer?  By moderator?
It wasn't me [:)]. Ah, Yashraj just confessed. Do you as originator have the option to reject the answer? I don't have questions so I could never check [:P]. I also don't know whether all users see (and can click) the This helped me link (moderators do).
And BTW - I didn't see your original post as threat, IMO you only started a thread.

Christian

Thanks Christian.  There are messages in the savlog.  

It is a bug in the sense that it seems to prevent the backup program from reading the file.  It happens every time, not just sometimes.  Weird.

Apologies for the typo, 'threat' should indeed be 'thread' :-)

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

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

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.

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 

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.