10.0.9 - Quota Resetting

Server
1

Hi all,

A quota I’m setting isn’t sticking.

Steps to reproduce

  1. Set quota
  2. Wait
  3. Profit

Expected behaviour

Tell us what should happen

Quota to stick

Actual behaviour

Tell us what happens instead

Quota resets to 20GB

Server configuration

Operating system:
Debian 8

Web server:
Apache

Database:
MySQL

PHP version:
5.6?

ownCloud version: (see ownCloud admin page)
10.0.9

Updated from an older ownCloud or fresh install:
Upgraded

Where did you install ownCloud from:
Debian repo

Signing status (ownCloud 9.0 and above):

Login as admin user into your ownCloud and access 
http://example.com/index.php/settings/integrity/failed 
paste the results into https://gist.github.com/ and puth the link here.

No errors have been found.

The content of config/config.php:

Log in to the web-UI with an administrator account and click on
'admin' -> 'Generate Config Report' -> 'Download ownCloud config report'
This report includes the config.php settings, the list of activated apps
and other details in a well sanitized form.

or 

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

*ATTENTION:* Do not post your config.php file in public as is. Please use one of the above
methods whenever possible. Both, the generated reports from the web-ui and from occ config:list
consistently remove sensitive data. You still may want to review the report before sending.
If done manually then it is critical for your own privacy to dilligently
remove *all* host names, passwords, usernames, salts and other credentials before posting.
You should assume that attackers find such information and will use them against your systems.

See config here: https://pastebin.com/gm58rW3h

List of activated apps:

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

Enabled:

  • activity: 2.3.7
  • comments: 0.3.0
  • configreport: 0.1.1
  • dav: 0.3.2
  • federatedfilesharing: 0.3.1
  • federation: 0.1.0
  • files: 1.5.1
  • files_external: 0.7.1
  • files_pdfviewer: 0.9.0
  • files_sharing: 0.10.1
  • files_texteditor: 2.2.1
  • files_trashbin: 0.9.1
  • files_versions: 1.3.0
  • files_videoplayer: 0.9.8
  • firstrunwizard: 1.1
  • gallery: 16.1.0
  • market: 0.2.4
  • notifications: 0.3.4
  • provisioning_api: 0.5.0
  • systemtags: 0.3.0
  • updatenotification: 0.2.1
  • user_external: 0.4
  • user_ldap: 0.11.0
    Disabled:
  • encryption
  • external

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/…
LDAP

2

I don’t think you can set quota for LDAP users, as their quota is set by the LDAP.

3

For almost 2 years I’ve set quotas using the quota tool under Users panel.

I’ve just checked, the quota field in oC LDAP configuration is empty, so the oC settings should stick

4

I think there was a change with the recent ownCloud version.

Now the LDAP quota field has priority above the ownCloud quota field.

5

Hi all,

I’ve managed to bodge my way around this. I used MySQL to increase the quota in the table for this user, I then updated the oC GUI to match. So far so good.

Not sure what the problem is, but GUI changes are not sticking.

6

Did you perform a user sync yet?

7

Don’t know if still relevant but there are 4 Types of Quota Settings in ownCloud when dealing with LDAP users.

  1. Quota Field

Found in User Authentication -> the Advanced Tab -> Special Attributes

This Setting beats the rest. If this is set, this is what will be set for a LDAP users’s quota in ownCloud

  1. Quota Default

Found in User Authentication -> the Advanced Tab -> Special Attributes

This is the fallback option if no Quota field is defined.

  1. User quota, this is what you set in the web UI drop down menu.

  2. Default Quota

This will be set if no quota is set.

Users Tab -> Gear Wheel, Default Quota.

Now, if you have 1. or 2. set, and try to set Quota via WebUI drop down menu - your setting will be overwritten by 1. or 2. This is what I think is happening in your case.

The solution is to clear 1. and 2, and then your setting will stick.

1 Like
8

1 and 2 have never been set. They are blank and have been since installation in 2016.

Anyway, like I said in the post before, updating the value in the DB manually and then in oC worked.

9

Hi!

Did you finally solve this?, I have the same problem after upgrading from version 9 to 10.

1 and 2 are empty, logged into a user account showing the quota value prior to the upgrade, then changed 3, refreshed the user’s browser and now it shows the updated one, but as soon as he logged out and in again, the quota reverts to its preious value.

Is seems that the value change somehow but the DB retains the previous one.

10

Hi, I Have the same problem as you Dsierra.

Someone finally solve this?

11

Check your DB Table oc_preferences. I think there are some values, to which oC resets the quota to.

12

Hi dmitry, thanks for your prompt reply!.

This is what the oc_preferences table contains for an user. If I changed the “files quota” value from “default” to “10 TB”, the user gets his quota changed and the admin Web UI reflects the new value.

Is here any wrong value?

core    lang    en
core    timezone        Europe/London
core    username        xxxxxxxx
documents       save_path
files   file_sorting    name
files   file_sorting_direction  asc
files   quota   default
files_external  config_version  0.5.0
firstrunwizard  show    0
login   lastLogin       1544534342
user_ldap       displayName     xxxxxxxx
user_ldap       firstLoginAccomplished  1
user_ldap       homePath
user_ldap       lastFeatureRefresh      1544538088
user_ldap       uid     xxxxxxxx

UPDATE:
I ran sudo -u www-data php occ user:sync “OCA\User_LDAP\User_Proxy” and now the “files quota” attributte is not longer there.

_UPDATE #2 _
Quotas are now on oc_accounts table and setting the quota on the WebUI is working again.