-
-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nextcloud displays wrong used storage #25283
Comments
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Does it work after you run |
Nope. It doesn't work. In Nextcloud it still says: 18.2GB used, but the disk only uses 9.3Gb... |
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. |
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. This is on Linux with Apache 2.4.41 and php 7.4.3 |
+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 |
same here Ubuntu 20.04.4 LTS, Apache 2.4.41, php 7.4.3, NC 24.0.3 |
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. |
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 |
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" In our case it's a shared Hetzner instance. They have no solution and cant reproduce it on their test system. |
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. |
I had the same issue. I ended up creating a backup of edit: Don't try this at home, kids. People - reported problems with this. |
Yeah, that definitely helps, just wonder why running 'occ files:scan --all' did not help WITHOUT truncating cache tables in database |
As suggested by @MichaelSp and confirmed by @Pinkbyte the only way for me to fix this was to truncate the |
Warning: Only truncate *c_filecache if you are not using encryption, otherwise all files are treated as plain unencrypted (and therefore unusable) afterwards! |
When I |
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. |
using NC25 with the same issue! |
Me, too. Even with NC25, the same issue occurs. |
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. Thoughts ? @icewind1991 |
I run the following command for my user to ensure that update oc_filecache set unencrypted_size=0 where encrypted=0 and unencrypted_size!=0 and storage=(select numeric_id from oc_storages where id=1); I then checked that this is correct by running the following request: select storage, size, unencrypted_size, etag from oc_filecache where storage=1 and path='files'; whic returns:
After a couple of minutes, I rerun the same command and now the
The files with
I am using Joplin (2.9.17). I will continue to check this a on a regular basis to see if I can find anything else interesting. |
Tools creating the issue:
Tools not creating the issue:
Other finding:
|
The total size below the file list also includes shared-in folders that do not count towards your own user's quota. Might this explain the difference for you, @ppfeufer ? |
No shared folders. |
I have the same issue: quota usage reported by Nextcloud is greater than actual disk usage, and only increases.
I'm not sure if the following error is related, but it is flooding my Logging app.
Thank you! |
For cases where encryption is enabled (or was previously enabled) , applying #36857 and running |
For anyone still facing the same issue even after applying the fix in #36857, you can try this steps:
For anyone working on this bug I have found a few things which migth help. Even after disabling the server side encryption, This is what I have dicovered today with the help of ChatGPT. Please let me know if this was helpful. |
Congratulations to ChatGPT, that was able to find a post in the same ticket just a few pages up... :) |
Is this fixed in a known release? |
The fix related to |
Given that this was mainly about instances with encryption is enabled, let's close this issue as fixed in #36857. If anyone still encounters issues with wrong quota calculation (on Nextcloud 27 or newer), please open a new issue about it. |
@mejo- I confirm that the issue is not reproducible with NC 27. |
Any plans to backport this to Nextcloud 25? @icewind1991 Is the fix in #36857 safe to apply to an instance running 25.0.9? Thanks 🫠 |
How to use GitHub
Steps to reproduce
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
No errors have been found.
List of activated apps:
App list
Notes, Decks, TasksNextcloud configuration:
Config report
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
Client configuration
Browser:
all / also in app
Operating system:
Logs
Web server error log
Web server error log
Nextcloud log (data/nextcloud.log)
Nextcloud log
Online:
The text was updated successfully, but these errors were encountered: