Sophos UTM-9.405-5 data disk filling up multiple times a week

Hi, Christian, and welcome to the UTM Community!

Before you delete the next batch of core dumps, show us the names of the files with ls -l to also see the sizes and dates.

Cheers - Bob

Hi Bob

Last friday i got some cssd.**** with a size from 3,2-4G

Today I've got cssd.22163 (3,3G), cssd.30480 (3,8G) and a mailsec-reporte.23283 on 9.8M

Hi Christian,

We're facing the same issue here. Since we have platinum support, I contacted Sophos support and got and answer... Well, if you can call that an answer: first got it in German then, when I requested an answer in English, I got this google translate... Sophos support quality is hitting an all-time low.

Anyway: here is the reply from support:

 Hello Mr. XXX, the problem is known to us and is not a UTM-whammy but a LABs Issue. 
 Colleagues SophosLabs are to fix the problem. 
 According to 3rd level support an IDE file should already have been published, which resolves the problem. 
 However, I have just picked out the Jira for the problem: CPISSUE-3649 JS emulation fail on customer sample 
 (memory consumption spike, hurting SEA) Here the bug is still unresolved status. 
 Current workaround looks that cssd core dump files should be deleted from the directory / var / storage / cores, 
 if the disc should be fully running. (What I've just done)

In other words: they know about it, it's a bug lost somewhere in between different Sophos department and the "solution" is to delete the core dumps by hand until they manage to solve it.

Excellent work - thanks, Stéphane!

If you feel comfortable  adding a cron job, add the following line to /etc/crontab-static

50 23 * * * root rm /var/cores/cssd.*

After that go into WebAdmin and force the regeneration of /etc/crontab by toggling the setting for 'Firmware Download Interval' to a diiferent period and then back.

Once someone announces that the problem is fixed, just delete the line from /etc/crontab-static and again force the regeneration of /etc/crontab.

Cheers - Bob

Excellent work - thanks, Stéphane!

If you feel comfortable  adding a cron job, add the following line to /etc/crontab-static

50 23 * * * root rm /var/cores/cssd.*

After that go into WebAdmin and force the regeneration of /etc/crontab by toggling the setting for 'Firmware Download Interval' to a diiferent period and then back.

Once someone announces that the problem is fixed, just delete the line from /etc/crontab-static and again force the regeneration of /etc/crontab.

Cheers - Bob

Thanks Bob, that's an excellent suggestion.

Stéphane

Hi all,

CSSD is ringing alarm bells from when talking to Support the other day that there are crash dumps being caused by the Sophos AV engine due to a problematic library load.

Set your AVs in their respective places to single scan and set the system settings to use the primary AV engine as Avira. Also take note (thanks Balfson) that setting the primary scanning engine to Avira and using Single Scan mode will disable Sandstorm protection as it requires the Sophos AV engine to operate.

You should see the issues go away until they resolve the bad library load.

Emile

Good point, Emile. If it's just a problem with savi patterns, they should be able to fix it quickly.

Those using Sandstorm need to know that it only works when the Sophos AV is active.

Cheers - Bob

Hi Bob,

Quite right on the Sandstorm! Added to my comment :)

Emile

Thank you all for the answers. 

And yes support is lacking a bit so it's nice we can figure things out together.