Sophos Anti-Virus for Linux: On-Access filesystem support

This article describes the filesystems supported for on-access scanning on Linux platforms.

The following sections are covered:

Known to apply to the following Sophos product(s) and version(s)

Sophos Anti-Virus for Linux 9 and Sophos Anti-Virus for Linux 10

Good filesystems

The following filesystems are known to work with Sophos Anti-Virus for Linux:

Filesystem Name Talpa Support? Fanotify Support?
btrfs Yes Yes
cifs Yes No
ecryptfs Yes Yes
ext2 Yes Yes
ext3 Yes Yes
ext4 Yes Yes
fuse Yes Yes
fuseblk Yes Yes
iso9660 Yes Yes
jfs Yes Yes
minix Yes Yes
msdos Yes Yes
ncpfs Yes Yes
nfs Yes Yes
nfs4 Yes* No
nssadmin Yes No
oes Yes No
overlayfs Yes Yes
overlay Yes Yes
ramfs Yes Yes
reiserfs Yes Yes
smbfs Yes Yes
tmpfs Yes Yes
udf Yes Yes
vfat Yes Yes
xfs Yes Yes
zfs Yes No

*Note: Talpa does not support locally mounted (non-network) nfs4 filesystems.

Unsupported filesystems

The following filesystems are unsupported. The majority of these are pseudo-filesystems that do not contain regular files and cannot be scanned.

Filesystem Name Talpa Support? Fanotify Support? Notes
aufs No No Pseudo-filesystem
autofs No No Pseudo-filesystem
binfmt_misc No No Pseudo-filesystem
bpf No No Pseudo-filesystem
cgroup No No Pseudo-filesystem
configfs No No Pseudo-filesystem
debugfs No No Pseudo-filesystem
devfs No No Pseudo-filesystem
devpts No No Pseudo-filesystem
devtmpfs No No Pseudo-filesystem
No No See KBA 118982
fusectl No No Pseudo-filesystem
inotifyfs No No Pseudo-filesystem
mqueue No No Pseudo-filesystem
nfsd No No Pseudo-filesystem
nsspool No No Pseudo-filesystem
proc No No Pseudo-filesystem
romfs No No Pseudo-filesystem
rootfs No No Pseudo-filesystem
rpc_pipefs No No Pseudo-filesystem
securityfs No No Pseudo-filesystem
selinuxfs No No Pseudo-filesystem
squashfs No No
subfs No No Pseudo-filesystem
sysfs No No Pseudo-filesystem
usbdevfs No No Pseudo-filesystem
usbfs No No Pseudo-filesystem

Other filesystems

Behavior with other filesystems will depend on the on-access interception method:

If you’ve spotted an error or would like to provide feedback on this article, please use the section below to rate and comment on the article.

This is invaluable for us to ensure that we continually strive to give our customers the best information possible.


Sophos Anti-Virus for Linux: Recommendations for On-Access scanning with Nautilus file browser

This article covers recommendations for On-Access scanning for Nautilus file browser.

Applies to the following Sophos product(s) and version(s)

Sophos Anti-Virus for Linux

Sophos Anti-Virus does not support the filesystem fuse.gvfs-fuse-daemon which is commonly used by the Nautilus file browser to mount remote shares. Git Virtual File System (GVFS) operations do not pass through the kernel as file operations and thus cannot be intercepted by the on-access scanner.

Sophos recommends to pre-mount remote shares using a different filesystem. For example, by using the mount command or configuring /etc/fstab.

If you’ve spotted an error or would like to provide feedback on this article, please use the section below to rate and comment on the article.

This is invaluable for us to ensure that we continually strive to give our customers the best information possible.


Re: Obtaining the DDBoostFS rpm

I don’t really understand your question.

So I’ll answer why I’m interested in BoostFS software.

BoostFS is a new client side optional component that allows the DDBoost storage unit to be mounted (similar to NFS mounts) and then you can use Linux commands to interact with the DDBoost Storage unit. Commands like ls, cp, rm will work. Without BoostFS, the only option I have for managing the files stored in DDBoost storage unit is via the API – which is clunky at best.

BoostFS implements a user space file system using the common FUSE Linux framework. There are many FUSE file systems. The chief benefit of FUSE is that it does not require changes to the Linux kernel. FUSE file systems are implemented in user-space so it’s more secure and easier to implement.

Hope that helps.


UBA 2.1.1 and new Machine Learning strangeness.

On QRadar 7.3.0 fixpack 4.
UBA 2.1.1 is now running and showing users.
I’m confused on the Status of the Machine Learning app.

[root@qradar tmp]# psql -U qradar -c “select name,id,status from installed_application;”
name | id | status ———————————–+——+——— User Analytics | 2905 | RUNNING Machine Learning Analytics | 2954 | RUNNING dataimport.ldap.applicationname | 2904 | RUNNING

BUT, in the “Machine Learning Settings” – I see this:
![alt text][1]

I ran the script successfully.

[root@qradar tmp]# python -t 7xxx2
Testing validity of token 7xxx2
Token 7xxx2 is valid
Checking QRadar version…ok
Checking if UBA Memory setting requires adjustment.
QRadar 7.3 detected UBA Memory setting does not require adjustment.
Docker memory in use: 7700 Mb
Max Docker memory available: 12874 Mb
Starting ML app upgrade process.
The ML app has been successfully upgraded.
Setting DSM entry to enabled…done
[root@qradar tmp]#

And then this…

![alt text][2]

[1]: /answers/storage/temp/17309-2017-09-14-095836.jpg
[2]: /answers/storage/temp/17310-2017-09-14-100802.jpg


Re: Avamar 7.X

Short answers first..

You can check the “Server utilization” value and compare it with the “Total Capacity”

admin@utilitynode:~/>: mccli server show-prop | grep “util|cap”

Total capacity 7.8 TB

Server utilization 32.5%

Regarding the use of the ‘’ script you can add –top=xx to set the number of highest consuming clients that will be listed at the end of the output

More info here:

  • KB 336542 – How to use script to analyse daily data change on the Avamar system
  • KB 457224 – Avamar User and OS Capacity Management Concepts and Training

A longer answer would be that you can think of an Avamar server license similar to an electrical appliance’s fuse.

An electrical appliance requires a fuse in order to operate. Remove the fuse and it will be useless.

Similarly, Avamar requires a valid license in order to function.

A fuse has a certain ‘resistance’ value associated to it which is matched to the level current that the appliance can safely handle.

Similarly, the Avamar server’s license is specified according to the back-end ‘GSAN’ storage available on the data nodes.

The similarities end here though as the size of the license doesn’t control how Avamar works or provide any safety ‘cut off’ with respect to capacity levels. Those are handled elsewhere. Whether the license is for 1TB or 50TB it doesn’t make a difference.. the mere existence of a valid license allows Avamar to run.

The sales team will provide an appropriately sized license to match the amount of data that can be stored on the Avamar server. The value corresponds to the size of and number of data nodes within the Avamar system. The amount of space required for RAIN overhead on multiple nodes is also part of that licensable value.

This is all supposed to be calculated during the pre-sales phase to ensure that the customer has an appropriately sized Avamar to suit their stated needs (number of and size of clients, the type of data they store, retention policies etc).

I’m not privvy to the sizing procedures or what other factors they take into account but once an Avamar server has been deployed as long as the longest retained client data we would expect it to be reasonably full.. with perhaps some spare capacity to account for unexpected spikes in new data. We regularly see customers accidentally backing up much larger datasets than originally intended so this is a sensible safety measure.

Note: This answer is tailored to a ‘traditional’ Avamar system where all backups are sent to the Avamar GSAN storage. For mixed systems or those where backups are sent only to DataDomain there are additional considerations and capacity measurements involved.