Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 3 subscribers
  • Views 2173 views
  • Users 0 members are here
Options
Suggested
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

Client runs out of disk space - how to repair?

Daniel Gebler

Dear All,

 

I face an issue on multiple machines where Sophos update fails once due to low disk space. 

I have found no other way to repair this than to reinstall the whole client from scratch. I tried deleting AutoUpdate's Cache and the status.xml, but once AU decides it cannot contact the server, it will stick to this message quite adamantly. Is there any other way to get an otherwise healthy install to re-try the update and actually make it go through with it correctly?

 

Thank you in advance

DanZi



This thread was automatically locked due to age.
  • 0

    Hello DanZi,

    you're not trying to re-enact every conceivable issue, are you? [;)]

    First and foremost you must ensure sufficient free space - and I daresay this is essentially all that's required. In most cases the next update succeeds. Under certain unfortunate circumstances the (Windows) Installer is not able to terminate gracefully - i.e. to perform the rollback as intended and revert all changes causing the next update to fail. Even then the next but one might succeed. Normally it's quite simple to deal with the remaining issues if you correctly identify them.
    Enough of the theory. it cannot contact the server should not be related to space problems. Is it indeed cannot contact or download failed - this is not the same? Deleting the Cache results in a re-download, rarely necessary but does no harm. status.xml is used to record on a per-component basis success or failure of the last update attempt w.r.t. the cache's state. Neither should be necessary in after an out-of-space condition (been there, done it). An incomplete cache will automatically be rebuilt, an update/install initiated of the cache has changed, a previously failed update/install retried.

    Christian

  • 0 in reply to QC

    "you're not trying to re-enact every conceivable issue, are you? [;)]"

    Haha :) I hope not.

    It's just I could never resolve such an issue without reinstall :( The client does complain about not being able to connect to the update location - and says no update point is specified. Although in iconn.cfg it has the correct address and it is accessible via UNC path as well as http without authentication. All subsequent updates fail, and due to the policies, local editing of update location is not possible via the gui. So cache folder stays empty... So I did what I always do... simply remove and reinstall =(

  • 0 in reply to Daniel Gebler

    Hello DanZi,

    no update point
    I have a case open, the issue dates back to at least 10.7.x. Endpoints claim Updating failed because no update source has been specified [0x0000006e] even though they report the correct location to SEC, you can change it from there, and you find it in the .cfg. The GUI fails (ALMon.exe might crash), the SAUConfigDLL.SAUConfig COM object returns an empty location, if you set one it does not persist. Also this message might alternate with Enhanced TP is enabled. In some cases it seems there was a preceding out-of-space condition, but I can't verify that this is true in all cases. Affects roughly 0.5% of the endpoints per year, almost none in the last months.

    A fix is promised for 10.8.5 (initially scheduled as Preview for May, at the moment not before August), obviously it takes some time to tell if it helps. It will definitely not heal the endpoints as they don't update. As far as I can tell you have to uninstall (and then reinstall) AutoUpdate - as running setup.exe initiates an uninstall of AU if it finds it installed there's no need for an explicit uninstall. At least setup.exe always did it for me, YMMV.

    Christian

Unfiltered HTML