v19 VMware disk usage, reporting full

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 https://support.sophos.com/support/s/article/KB-000036775?language=en_US. It is worth trying this after update? Or do we have reinstall XG firewall again and restore config from backup?

Hi,

Are there any suggestions for this yet?
We are also affected and have 5 productive instances!

SFOS 19.0.1 MR-1 build350 is not available as install image and seems to be withdrawn today also as update???

We need a way of repair without reinstalling!

BR Gerd

It is fixed in MR1. The Build Version does not matter. You should have access to V19.0 MR1 in your Licensing Portal. community.sophos.com/.../sophos-firewall-v19-mr1-re_2d00_release-build-365-is-now-available

Hi Lucar,

19.0.1 MR-1 is available as an update, but NOT as an installation media.
But if you click on "check for updates" in a firewall today, it says "no update available". That was different yesterday!

On the other hand you answeresat not my question!

The update does not fix the error with the var directory!

So the question remains:
How can the problem be fixed without reinstalling??

I opened a case regarding this issue (NC-94291)

BR Gerd

This could be related to V19.0 MR1. See: https://community.sophos.com/sophos-xg-firewall/b/blog/posts/sophos-firewall-v19-mr1-re_2d00_release-build-365-is-now-available

There are two fixes: 

NC-100679 & NC-94291

So you can update your current installation to V19.0 MR1 and try it. The Respin version fixed another issue, which could potentially caused this issue. 

Hi Toni, thank you for quick response. I need to explain your "... try it...". You mean - after update the /var would be "expanded" after update will have finished? Or we need export-reinstall-import? Or you don´t know and mean "maybe the /var size changed after reinstall"?

As I wrote: The update does not fix the error with the var directory!

Of course I checked before I wrote that!

SFVUNL_KV01_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     24.0K      1.9G   0% /dev
none                      1.9G     51.7M      1.9G   3% /tmp
none                      1.9G     14.6M      1.9G   1% /dev/shm
/dev/boot               127.7M     34.3M     90.7M  27% /boot
/dev/mapper/mountconf
                        560.3M     72.0M    484.3M  13% /conf
/dev/content             11.8G    496.1M     11.3G   4% /content
/dev/var                  3.7G      1.5G      2.2G  41% /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. 

This Firewall is brandnew (installed yesterday)

And we have another that is 3 weeks old, there it is on 100 %!

Sorry Luca, please don't think I'm stupid, but your answer is simply wrong.

There is an nc-94291 for this issue and you try to say 41% is fine........

Here is an example how it should be. (appliance has been updated from 18.x)

SFV1C4_SO01_SFOS 19.0.0 GA-Build317# df -h
Filesystem                Size      Used Available Use% Mounted on
none                    231.4M     12.6M    202.6M   6% /
none                      1.9G     20.0K      1.9G   0% /dev
none                      1.9G     21.5M      1.9G   1% /tmp
none                      1.9G     14.6M      1.9G   1% /dev/shm
/dev/boot               127.7M     50.0M     75.0M  40% /boot
/dev/mapper/mountconf
                        385.4M     73.1M    308.3M  19% /conf
/dev/content              3.6G    601.6M      3.0G  16% /content
/dev/var                 29.9G      8.6G     21.3G  29% /var

This Firewall is brandnew (installed yesterday)

And we have another that is 3 weeks old, there it is on 100 %!

Sorry Luca, please don't think I'm stupid, but your answer is simply wrong.

There is an nc-94291 for this issue and you try to say 41% is fine........

Here is an example how it should be. (appliance has been updated from 18.x)

SFV1C4_SO01_SFOS 19.0.0 GA-Build317# df -h
Filesystem                Size      Used Available Use% Mounted on
none                    231.4M     12.6M    202.6M   6% /
none                      1.9G     20.0K      1.9G   0% /dev
none                      1.9G     21.5M      1.9G   1% /tmp
none                      1.9G     14.6M      1.9G   1% /dev/shm
/dev/boot               127.7M     50.0M     75.0M  40% /boot
/dev/mapper/mountconf
                        385.4M     73.1M    308.3M  19% /conf
/dev/content              3.6G    601.6M      3.0G  16% /content
/dev/var                 29.9G      8.6G     21.3G  29% /var

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
/dev/mapper/mountconf
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.

Regards

alda

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

I will not respond to this thread anymore, as i cannot help you any further. 

All information are available. The bug is fixed. You need to reinstall with the new V19.0 MR1 installer or an old installer. 

Hi Lucar,

I can understand your despair. But there is still no acceptable solution from your employer SOPHOS!

Your last solution approach in unacceptable, as now really described several times!

Sorry dear community members, but actually this time I wanted to give Sophos a chance to really admit mistakes and generate a sound solution.
BR Gerd

LuCar Toni said:

All information are available. The bug is fixed. You need to reinstall with the new V19.0 MR1 installer or an old installer. 

this one is not available!

As I write now for several post!
What is this solution approach??

We are working on publishing the MR1 installers as we speak, I'll update this when they're available. 

Hello guys,

as long as we don't get a solution from Sophos, the only steps you can take are as follows:

1. reduce the report holding time to the lowest possible value
2. flush report data on the shell.

I unfortunately have to do this every 2nd day now because our customer appliance is more than 500 km away.

@Sophos great bug, keeps us at work

SOLVE IT!