Nextcloud displays wrong used storage

[olizimmermann]

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Steps to reproduce

1. Install Nextcloud
2. Create some users
3. Upload some data
4. check at the users overview the used storage
5. compare it with the real used storage within the users folder via shell

Expected behaviour

Tell us what should happen Should be 1:1 like all my other users.

Actual behaviour

Tell us what happens instead Real used storage: 9.3 Gb Nextcloud shows me: 18.2

Server configuration

Operating system: FreeBsd Web server: Nginx Database:

PHP version: 7.04 Nextcloud version: (see Nextcloud admin page) 20.0.5 Updated from an older Nextcloud/ownCloud or fresh install:

Where did you install Nextcloud from: TrueNas - Plugin - latest Update via Updater Signing status:

Signing status

Login as admin user into your Nextcloud and access 
http://example.com/index.php/settings/integrity/failed 
paste the results here.

No errors have been found.

List of activated apps:

App list

Notes, Decks, Tasks

If you have access to your command line run e.g.:
sudo -u www-data php occ app:list
from within your Nextcloud installation folder

---

Nextcloud configuration:

Config report

If you have access to your command line run e.g.:
sudo -u www-data php occ config:list system
from within your Nextcloud installation folder

or 

Insert your config.php content here. 
Make sure to remove all sensitive content such as passwords. (e.g. database password, passwordsalt, secret, smtp password, …)

CONFIG = array ( 'apps_paths' => array ( 0 => array ( 'path' => '/usr/local/www/nextcloud/apps', 'url' => '/apps', 'writable' => true, ), 1 => array ( 'path' => '/usr/local/www/nextcloud/apps-pkg', 'url' => '/apps-pkg', 'writable' => true, ), ), 'logfile' => '/var/log/nextcloud/nextcloud.log', 'passwordsalt' => 'XXXXX', 'secret' => 'XXXXX', 'trusted_domains' => array ( 0 => 'localhost', ), 'datadirectory' => '/usr/local/www/nextcloud/data', 'dbtype' => 'mysql', 'version' => '20.0.5.2', 'overwrite.cli.url' => 'http://localhost', 'overwriteprotocol' => 'https', 'dbname' => 'nextcloud', 'dbhost' => 'localhost', 'dbport' => '', 'dbtableprefix' => 'oc_', 'mysql.utf8mb4' => true, 'dbuser' => 'XXX', 'dbpassword' => 'XXX', 'installed' => true, 'instanceid' => 'XXX', 'twofactor_enforced' => 'false', 'twofactor_enforced_groups' => array ( 0 => 'admin', ), 'twofactor_enforced_excluded_groups' => array ( ), 'mail_smtpmode' => 'smtp', 'mail_sendmailmode' => 'smtp', 'mail_domain' => 'gmail.com', 'mail_smtphost' => 'smtp.gmail.com', 'mail_smtpport' => '587', 'mail_smtpsecure' => 'tls', 'mail_smtpauthtype' => 'LOGIN'..

Are you using external storage, if yes which one: local/smb/sftp/... No Are you using encryption: yes/no No Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/... No

LDAP configuration (delete this part if not used)

LDAP config

With access to your command line run e.g.:
sudo -u www-data php occ ldap:show-config
from within your Nextcloud installation folder

Without access to your command line download the data/owncloud.db to your local
computer or access your SQL server remotely and run the select query:
SELECT * FROM `oc_appconfig` WHERE `appid` = 'user_ldap';


Eventually replace sensitive data as the name/IP-address of your LDAP server or groups.

Client configuration

Browser: all / also in app Operating system:

Logs

Web server error log

Web server error log

Insert your webserver log here

Nextcloud log (data/nextcloud.log)

Nextcloud log

Insert your Nextcloud log here

Shell:

Online:

[szaimen]

Is this Issue still valid in NC21.0.2? If not, please close this issue. Thanks! :)

[olizimmermann]

Is this Issue still valid in NC21.0.2? If not, please close this issue. Thanks! :)

Still valid.

[szaimen]

Does it work after you run occ files:scan sz and occ files:cleanup?

[olizimmermann]

Does it work after you run occ files:scan sz and occ files:cleanup?

Nope. It doesn't work. In Nextcloud it still says: 18.2GB used, but the disk only uses 9.3Gb...

[pierr0t]

Hello,

It's a problem I discussed on the forums ... I use "Quota Warning" app in Nextcloud, but my problem is the opposite, for example in a NC 21.0.3 instance with a single user (he uses it to sync between 3 machines) the NC interface shows 94gb used and the "Quota warning" app reports 94% usage because I did set a 100GB quota for that user, so far so good.

Problem, if I check on the server itself (debian 10 up to date) the real usage is 152GB. I was explained that the quota do not account for the deleted files, the versions, etc ... so this makes user's quota completely useless, in this case I put a 100GB quota so the client is notified when reaching 90GB but on the server the client already reached 150GB ... This already lead to his NC beeing stuck because the server quota at 200GB was reached (and Debian blocked additional files) while the client thought everything was fine (he was seeing 15OGB usage).

I see the problem on all my NC instances (14), most of the time the storage as seen on the server largely exceeding the quota in NC ... I do not recall seeing the opposite like you do and generally I see the problem for all users not only one, so my problem might be different from you but I am continuously searching for new info on that problem so I thought I would follow this thread.

[alars]

On an NC 24.0.2 instance (with only local storage) the NC 'Users' page shows disk usage that is way off for half of the users and (almost) correct for the other half. Example: User 1: actual disk usage 151GB, displayed usage only 648.8MB; user 2: actual disk usage 376GB, displayed usage only 2.3GB Neither occ files:scan --all nor occ files:cleanup fixes the issue.

This is on Linux with Apache 2.4.41 and php 7.4.3

[Pinkbyte]

+1 for this issue.

Nextcloud deployed from docker container (Image - nextcloud:24.0.3)

du -hs for ENTIRE Nextcloud data folder shows me 28,3 Gb, while in web interface for one user(which has most of this data) it is shown as 37,2 Gb used.

No external storage. Versions and trashbin plugins are enabled though

[htc1977]

On an NC 24.0.2 instance (with only local storage) the NC 'Users' page shows disk usage that is way off for half of the users and (almost) correct for the other half. Example: User 1: actual disk usage 151GB, displayed usage only 648.8MB; user 2: actual disk usage 376GB, displayed usage only 2.3GB Neither occ files:scan --all nor occ files:cleanup fixes the issue.

This is on Linux with Apache 2.4.41 and php 7.4.3

same here user 1 real usage: 19.8 GB -> nextcloud shows 2,9 GB user 2 real usage: 41.2 GB -> nextcloud shows 62 KB

Ubuntu 20.04.4 LTS, Apache 2.4.41, php 7.4.3, NC 24.0.3

[jshatch]

I have run into something similar to the issue reported here, it may be the same thing. My user has about 250GB of data but the UI reports only 78MB used. I had run out of my quota at 250GB and it was reporting I could not upload any more, but it was saying 78MB/78MB used. When I upped the quota to 500GB it now reports 78MB/250GB used. I deleted a large file from my instance that would have very easily sent that 78MB number into the negative by a few GB, and it didn't move. The total briefly showed 500GB after that, but upon refreshing the page it returned to the previous value. Something is wrong, none of the DB repair or file scan occ commands do anything. I updated to 24.0.4 today and there is no change. Access to files is not affected, just reporting of space used.

[eloo]

i see the same issue with 24.0.4

one user has aroung 12gb data but nextcloud is reporting 164kb :D

Please fix that. This makes the quota feature really unusable

[dominictrier]

We are seeing something similar to this i believe. (24.0.3)

It seems the updating of Folder sizes after deleing is severely delayed or not happening at all. Like is "sticky" After deleting a file from a folder the folder size is not updated and the old size keeps counting against the quota. Looking at the same folder via Filesystem or Webdav shows them as 0kb. This is mostly affecting our main user, used for sharing out folders to the other users.

In our case it's a shared Hetzner instance. They have no solution and cant reproduce it on their test system. They basically gave up and suggested to try to post on github and hope for the best.

[simonspa]

I also see this issue, and it persists with NC 24.0.5:

du -hs ncdata/username
80G	ncdata/username

[eidermar]

We are seeing something similar to this i believe. (24.0.3)

It seems the updating of Folder sizes after deleing is severely delayed or not happening at all. Like is "sticky" After deleting a file from a folder the folder size is not updated and the old size keeps counting against the quota. Looking at the same folder via Filesystem or Webdav shows them as 0kb. This is mostly affecting our main user, used for sharing out folders to the other users.

In our case it's a shared Hetzner instance. They have no solution and cant reproduce it on their test system. They basically gave up and suggested to try to post on github and hope for the best.

We are also with Hetzner and the reported "GB used" value from within the web-interface is almost half from the actual space used according to the Hetzner console. As there is no access via terminal or a web-console I'm having a hard time to troubleshoot this. I suspect that there are leftovers from failed uploads somewhere in the file system as reported in other threads with similar topics. We tried deleting all individual as well as admin trash bins and looked through TBs of files to see if any excessive versioning was going on somewhere...without any success. Is there really no way to show the allocation of data in the web-interface? Or does anybody have any other idea what else we could try to get rid of this junk (almost 500GBs) that is obviously comfortably lurking around somewhere and blocking valuable space...without having access to the file structure or a command line?

TIA

[simonspa]

We are seeing something similar to this i believe. (24.0.3) It seems the updating of Folder sizes after deleing is severely delayed or not happening at all. Like is "sticky" After deleting a file from a folder the folder size is not updated and the old size keeps counting against the quota. Looking at the same folder via Filesystem or Webdav shows them as 0kb. This is mostly affecting our main user, used for sharing out folders to the other users. In our case it's a shared Hetzner instance. They have no solution and cant reproduce it on their test system. They basically gave up and suggested to try to post on github and hope for the best.

We are also with Hetzner and the reported "GB used" value from within the web-interface is almost half from the actual space used according to the Hetzner console. As there is no access via terminal or a web-console I'm having a hard time to troubleshoot this. I suspect that there are leftovers from failed uploads somewhere in the file system as reported in other threads with similar topics. We tried deleting all individual as well as admin trash bins and looked through TBs of files to see if any excessive versioning was going on somewhere...without any success. Is there really no way to show the allocation of data in the web-interface? Or does anybody have any other idea what else we could try to get rid of this junk (almost 500GBs) that is obviously comfortably lurking around somewhere and blocking valuable space...without having access to the file structure or a command line?

TIA

So in my case it definitely is not leftovers from deleted files or versions. This is read data. I am hosting my own server, so I have full access to cli and database, but I'm not sure what info could help.

I am positive that this is just a problem in calculating the storage on the Nextcloud side, because both the user folder on the server as well as my locally synced data folder with the NC desktop client report > 70 GB of data being present.

[MichaelSp]

I had the same issue. I ended up creating a backup of oc_filecache, TRUNCATE TABLE oc_filecache and running occ files:scan --all. Now it looks better.

edit: Don't try this at home, kids. People - reported problems with this.

[Pinkbyte]

I had the same issue. I ended up creating a backup of oc_filecache, TRUNCATE TABLE oc_filecache and running occ files:scan --all. Now it looks better.

Yeah, that definitely helps, just wonder why running 'occ files:scan --all' did not help WITHOUT truncating cache tables in database

[tobyheywood]

As suggested by @MichaelSp and confirmed by @Pinkbyte the only way for me to fix this was to truncate the nc_filecache table and then run files:scan --all Thanks for sharing the workaround

[alars]

Warning: Only truncate *c_filecache if you are not using encryption, otherwise all files are treated as plain unencrypted (and therefore unusable) afterwards!

[htc1977]

When I truncate table oc_filecache and run occ files:scan --all, all my shares and favorites are gone. :(

[jshatch]

Rather than truncating tables or other hacks I would really like to see a dev weigh in on this issue and fix it in the code.

[anguschang007]

using NC25 with the same issue!

[seieric]

Me, too. Even with NC25, the same issue occurs.

[PVince81]

I had this too, the problem was that some of the size accounting was not up to date.

Background: to optimize size propagation, Nextcloud uses an algorithm that adds or substracts sizes across all parent folders of a modified path. If for some reason this didn't happen, for example if the PHP process got killed shortly after an upload, the oc_filecache will contain wrong values.

Now, the "occ files:scan" command doesn't automatically fix sizes. I'd say the "occ files:scan" command should be extended to also fix folder sizes since it's anyway going to go through all folders.

Thoughts ? @icewind1991

[szaimen]

Hi, please update to at least 23.0.12 and report back if it fixes the issue. Thank you!

[seieric]

Nextcloud 25.0.2 with main storage encryption still shows wrong quota.

[mejo-]

I experience the same issue on a 24.0.7 instance. Thanks for the explanation @PVince81. I agree that occ files:scan should recalculate and update the sizes. Or at least we should provide an occ command to recalculate the file sizes.

[varac]

Same here on 24.0.7.

[tobexyz]

same here on 25.0.1

[SudipBatabyal]

Same issue with nextcloud 25.01

[doobry-systemli]

Is there any way to force Nextcloud to manually recalculate the used storage of users? On our instance, more and more users hit their quota due to this issue unfortunately (version 24.0.7).