Available disk space is critically low, less than 20 MB available. Proceed with

Hi,

A few things you might try (maybe you already have):

1. Clear Browser Cache: Sometimes, browser cache can cause inconsistencies in displaying accurate information. So you could try clearing that and checking again.
2. Check Hosting Environment: You could ask your host if there’s anything wrong their end.
3. Regenerate Site Health: Sometimes, site health information can become outdated or corrupted. You can try regenerating the site health data by using the “Site Health” tool in the dashboard.
4. Verify Plugin Compatibility: You mention you had to disable some plugins to get your site working after the update. Maybe a one of those or a different plugin causing the incorrect disk space information. You could try switching them all off and then reactivate one by one.
5. Reinstall 6.3: It sounds like something may have gone wrong with the udate, so you might want to consider manually reinstalling WordPress version 6.3.

I hope that helps…

I’m afraid none of those solutions fixed the problem, in the end I just downgraded. I have a feeling it might be related to mariadb but it’s only a guess/hunch

So, in case anyone is looking here, I have done a full update to everything (mariadb, php etc) and the problem continues. So, I’m not sure what the problem is. Oh and if anyone is wondering, it was goodlayout LMS that had to be turned off to allow the update to 6.3 to happen (otherwise you’ll be locked out of the site).

Anyone have anything else I can try?

@mathsgrinds I am confused with the statement if the memory is less than 20MB then ask your hosting provider to increase it. If its 26GB available, I would suggest to again contact your hosting provider. Because, if above problems cant fix it then you hosting provider can do.
Thank you

I am self-hosting in a pi4, there is no problem with storage, I have 26 GB free but wordpress “thinks” I only have 20 MB free however I think that is a false warning because I can still do things like upgrade/downgrade etc. Something is causing a misreading. I mean I’m sure it is a misreading because I can plainly see I have 26 GB free. And the error goes when I dowgrade, so something is wrong with 6.3 for me.

I’m currently on Bullseye with Marida-DB updated to 10.5, so, it might not matter ??

The function producing the error message was recently added to 6.3, see WP_Site_Health::get_test_available_updates_disk_space() | Method | WordPress Developer Resources, so my guess is something is wrong with the function but I’m not sure what. Maybe someone with more PHP and WordPress knowledge can help.

I edited the code to show how much free space and it is negative!

(-390381568 bytes) Available disk space is critically low, less than 20 MB available. Proceed with caution, updates may fail.

So my “fix” was to change the code in the function to the following:

                if ( $available_space < 0  ) {
                        //$result['description'] = __( "Available disk space is negative, something went wrong. $available_space bytes" );
                        //$result['status']      = 'recommended';
                }

                elseif ( $available_space < 100 * MB_IN_BYTES ) {
                        $result['description'] = __( 'Available disk space is low, less than 100 MB available.' );
                        $result['status']      = 'recommended';
                }

                elseif ( $available_space < 20 * MB_IN_BYTES ) {
                        $result['description'] = __( 'Available disk space is critically low, less than 20 MB available. Proceed with caution, updates may fail.' );
                        $result['status']      = 'critical';
                }

                elseif ( ! $available_space ) {
                        $result['description'] = __( 'Could not determine available disk space for updates.' );
                        $result['status']      = 'recommended';
                }

• This reply was modified 1 year, 3 months ago by mathsgrinds.
• This reply was modified 1 year, 3 months ago by mathsgrinds.

PS: I also needed to add define(‘WP_CONTENT_DIR’, ‘location of content dir’); into config

@mathgrinds. I have the same problem with my installation on a pi3. The error is indeed in the function you mentioned.

WP_Site_Health::get_test_available_updates_disk_space() | Method | WordPress Developer Resources

On line 1946

$available_space = false !== $available_space
? (int) $available_space
: 0;

The cast (int) $available_space causes the issue, the issue is caused if you have to much free space. Then this cast returns a negative number. In my case:
$available_space => 42632790016
(int) $available_space => -316882944

I am not a php expert but repairing this error should be trivial to one of the developers

Ah interesting, so, will I leave my code change as is and wait for the next update to fix it? Thanks for confirming, I didn’t even consider too much space being a problem in this day and age! Reminds me of the Broken Sword 1 installation bug. lolz

(My code I posted above is pending approval)

• This reply was modified 1 year, 3 months ago by mathsgrinds.

As a test I removed the cast to int, I changed
$available_space = false !== $available_space? (int) $available_space: 0;
into
$available_space = false !== $available_space? $available_space: 0;

I now get in the passed tests:
40 GB available disk space was detected, update routines can be performed safely.

I don’t know whether developers are reading this forum and how to make them aware of the error.

Thank you so much @henryjanssen, so, for anyone else reading this, the fix for now is to go to wp-admin/includes/class-wp-site-health.php and on line 1947 change ? (int) $available_space to ? $available_space

The error is caused when you have too much free space and converting to an integer causes the overly large number to roll into the negatives. I’ll report it now.

Ticket: #59116 (Integer Casting Error in WP_Site_Health::get_test_available_updates_disk_space() wordpress) – WordPress Trac

I’ll mark this as resolved ?? I guess…

I confirm that the proposed fix works here (on Raspberry Pi-4 with 32G SD-card, running php-8.2.8).