Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

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

v19 VMware disk usage, reporting full

I've deployed last Sunday and migrated SFOS 19.0.0 GA-Build317 from old SFV4C6 to this new one (because of swap problems). Veeam ONE Monitor starts to send Guest disk space "/var" alarms today. It looks like SFOS v. 19 image has much less space for /var than v. 18.5. (along to

SFV4C6_VM01_SFOS 19.0.0 GA-Build317# fdisk -l
Disk /dev/sda: 16 GB, 17179869184 bytes, 33554432 sectors
2088 cylinders, 255 heads, 63 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device  Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/sda1    1023,254,63 1023,254,63   33144832   33423359     278528  136M 83 Linux
/dev/sda2    1023,254,63 1023,254,63   33423360   33554431     131072 64.0M 83 Linux
Disk /dev/sdb: 80 GB, 85899345920 bytes, 167772160 sectors
10443 cylinders, 255 heads, 63 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Disk /dev/sdb doesn't contain a valid partition table

SFV4C6_VM01_SFOS 19.0.0 GA-Build317# df -h
Filesystem                Size      Used Available Use% Mounted on
none                    640.6M     11.6M    582.3M   2% /
none                      2.9G     24.0K      2.9G   0% /dev
none                      2.9G     16.9M      2.9G   1% /tmp
none                      2.9G     14.7M      2.9G   0% /dev/shm
/dev/boot               127.7M     26.6M     98.4M  21% /boot
                       560.3M     93.4M    462.9M  17% /conf
/dev/content             11.8G    493.4M     11.3G   4% /content
/dev/var                  3.7G      3.5G    174.5M  95% /var

SFV4C6_VM01_SFOS 19.0.0 GA-Build317# df -m /var
Filesystem           1M-blocks      Used Available Use% Mounted on
/dev/var                  3776      3589       170  95% /var

SFV4C6_VM01_SFOS 19.0.0 GA-Build317# du -d 1 -m /var/|sort -nr|head
2995    /var/
945     /var/tslog
742     /var/newdb
565     /var/eventlogs
218     /var/savi
204     /var/tmp
192     /var/avira4
46      /var/sasi
24      /var/conan_new
24      /var/conan

BTW I have no idea why "df -m /var" differs from "du =ms /var".

SFV4C6_VM01_SFOS 19.0.0 GA-Build317# df -m /var/ && du -ms /var/
Filesystem           1M-blocks      Used Available Use% Mounted on
/dev/var                  3776      3561       199  95% /var
2967    /var/

It could be resolved on v19 MR-1 but I can't see it in Resolved issues. Anyway I get "No records found" if I check for new firmware.

I've tried to find how to purge report logs but firewall help is not very instructive. What is the recommended procedure?

This thread was automatically locked due to age.
  • This could be:  NC-94291

    Fixed in MR1. 


  • I think and believe that this problem (NC-94291) is fixed in build 350. But it is possible to correct this problem on a "live system"? When we updated another firewall, the /var filesystem REMAIN small. I have found some info about "increasing /var size" in It is worth trying this after update? Or do we have reinstall XG firewall again and restore config from backup?

  • Hi Thomas

    The update does not seem to do anything (see below, checked on a brand-new appliance)

    I'm still waiting for a solution from Sophos support, but it's very tough here as usual :-(
    Although the error should actually be known.......

    Before Update

    console> system diagnostics show disk

    Partition        Utilization(%)


    configuration         9%

    content               3%

    report               34%


    SFVUNL_HV01_SFOS 19.0.0 GA-Build317# df -h

    Filesystem                Size      Used Available Use% Mounted on

    none                    640.9M     11.6M    582.7M   2% /

    none                      1.9G     24.0K      1.9G   0% /dev

    none                      1.9G     12.9M      1.9G   1% /tmp

    none                      1.9G     14.6M      1.9G   1% /dev/shm

    /dev/boot               127.7M     26.9M     98.1M  21% /boot


                            560.3M     51.9M    504.4M   9% /conf

    /dev/content             11.8G    393.0M     11.4G   3% /content

    /dev/var                  3.7G      1.2G      2.4G  34% /var


    After Update

    console> system diagnostics show disk

    Partition        Utilization(%)


    configuration        13%

    content               3%

    report               35%



    SFVUNL_HV01_SFOS 19.0.1 MR-1-Build365# df -h

    Filesystem                Size      Used Available Use% Mounted on

    none                    613.2M      1.5M    567.0M   0% /

    none                      1.9G     32.0K      1.9G   0% /dev

    none                      1.9G     12.6M      1.9G   1% /tmp

    none                      1.9G     14.6M      1.9G   1% /dev/shm

    /dev/boot               127.7M     34.3M     90.7M  27% /boot


                            560.3M     71.6M    484.7M  13% /conf

    /dev/content             11.8G    386.1M     11.4G   3% /content

    /dev/var                  3.7G      1.3G      2.4G  35% /var

  • We are not increasing the the /var/ because there is no reason to do. But 41% is actually fine from my perspective. /var/ is rarely used. 
    It´s not fine! As I wrote several times!
    We have appliances that are 100% filled after a few weeks.

    The only thing that helped here was to flush device reports and set the report storage duration to the shortest time interval!

    But obviously, once again, no one at Sophos wants to know anything about it.

  • I do not wont to be rude, but my answer is pretty clear: 

    Let me rephrase this: 

    There are different points. And you are starting to mix up certain points: 

    First of all, there are Bugs, which let the /var/ partition fill up. Those root causes are fixed in V19.0 MR1. So the /var/ is not increasing "unexpectedly". Due the fact, that /var/ is used for other things like reporting, it is natural to increase over time, but will be flushed after a while by the settings of the system (Report settings).
    This is fixed by  NC-94291 & NC-100679 - So no unexpected increase of /var/. 

    The current ISO of V19.0 MR1 is not available due the fact, V19.0 MR1 got a respin. Therefore we do not want to push Build350 to the public anymore. The team is currently working on getting ISOs pushed out. The problem is: You have regulations, which has to be hit (Software Export compliance etc.). 

    You can install V18.5 MR4 and upgrade to V19.0 MR1 with the SIG File, you find on your portal. V19.0 MR1 is not available for machines via up2date. And i posted no advise to "restore" the backup. I talked about do a V18.5 MR4 installation, upgrade it and then restore. Maybe this was not clear from my end. 

    There is only a way to reinstall from my perspective. If you disagree, feel free to open a new case with Support to discuss this further. 


  • I don't want to be rude either. But my question is pretty clear too:

    What exactly is being addressed in NC-94291? I can see

    NC-94291 Firmware Management Small var partition created for VM image using an auxiliary disk.

    The problem is "Small var partition created for VM image using an auxiliary disk.". How is this solved?

    Not a word about "Bugs, which let the /var/ partition fill up". Maybe I don't understand well Sophos language.

    I consider logs and reports to be "expected increase of /var/" and I'm surprised that Sophos doesn't see it as their problem that installing creates /var of a size that fills up with logs and reports in a week on a busy firewall and prevents the MTA from using /var/spool.

    I have reported the issue to local support and am awaiting a response.

  • Essentially MR1 and this ID: NC-94291 will fix the installation size of the /var/ partition. We cannot change this after an installation. So if you use the new (not released V19.0 MR1 Installer), it will use the proper Size of the Aux and use it for /var/. 

    It will not solve the current situation of your installation. This was not proper communicated through the channel as well. It will be entered to the KIL (known issue list) as well soon to inform everybody. 

    The current only solution, would be using V18.5 Installers and upgrade to V19.0 MR1 with a SIG file. 

    Here you find all installers: 

    Then use the V18.5 MR4 installer. Due the installations. Jump to the end and do not restore your backup. Then upgrade via SIG to V19.0 MR1. After upgrade restore you backup and you should be fine. With reboots, you should be good to go in 15 minutes. 


  • Hello Gerd,

    according to the SFOS version, you have a virtual version of SFOS. How big a virtual disks do you have in Hyper-V/ESXi hypervisor? In my case, I have 16GB and 80GB virtual drives and disk partition sizes are as follows:

    SFV4C6_VM01_SFOS 19.0.1 MR-1-Build350# df -h
    Filesystem Size Used Available Use% Mounted on
    none 612.8M 11.4M 556.6M 2% /
    none 2.9G 48.0K 2.9G 0% /dev
    none 2.9G 26.7M 2.9G 1% /tmp
    none 2.9G 14.7M 2.9G 0% /dev/shm
    /dev/boot 127.7M 34.0M 91.0M 27% /boot
    560.3M 74.7M 481.6M 13% /conf
    /dev/content 11.8G 638.0M 11.2G 5% /content
    /dev/var 70.7G 15.9G 54.8G 22% /var

    I think your /var disk size is only about 4GB because it was the original version of that disk for v17/v17.5, if I remember correctly.
    The installer from v18+ creates two virtual disks of 16 GB and 80 GB. I know that in the release notes for v18.0 it was recommended to install SFOS as a new system due to the greater demands on disk space for this and other versions.



  • This issue only occur by using the V19.0 EAP2 or GA Installer. Other installers are not affected. 


  • Hi Luca,

    I don't want to be offensive, but do you read your own posts?
    A large manufacturer only offers solutions at the expense of the customer????

    You can read all about it here!
    Just once more.

    - Sophos distributes a faulty installer.
    - Solution is the new MR1 version, which is not available! (checked just one Minute ago!)
    (That means faulty new installs every day!).
    - Solution 2 "just install the old 18.5.x ! (which is officially no longer available!)

    Hi Luca, who bears the costs if this measure has to happen at a customer 500 km away????
    I know it like this: Whoever makes the mistake has to pay.

    I am currently leaning towards solution 2, but with a firmware from another manufacturer.....

    Unfortunately, this is not the first time I have experienced something like this at SOPHOS!

    When will you finally wake up?

    Greetings Gerd

  • ... and Luca,

    stop minimising the problem, even though you're getting paid for it.

    Sometimes it's better to admit your mistakes!

    Greetings Gerd

  • It´s a BUG from Sophos but they ignore it until today!

    BR Gerd

Reply Children