Quota resets to previous value using User_LDAP for authentication


#1

I’ve already filed a proper bug report on github, but want to put this here in case it helps anyone else. Briefly:-
we use the user_LDAP plugin for authentication against out corporate AD, that’s all just authentication, no quota values are configured in the LDAP plugin, or in AD.
If I change the users quota in the admin webpage, it changes to the new value, and this is reflected in the oc_accounts database table in the quota field for that user.
However as soon as the user logs in to the webpage or their client performs a sync, the value resets to the previous one.
To change a users quota I have to change the configvalue field for the quota configkey for the user in the oc_preferences table. this value does not update when the quota is changed via the admin webpage.


#2

Could you post the link to your bug report?


#3

#4

Can you look at this document and check that you have your configuration right?

https://doc.owncloud.com/server/10.0/admin_manual/configuration/user/user_configuration.html?highlight=quota#setting-storage-quotas

I just tested it, and I can give my LDAP user quotas in the web UI. It does not reset after either I log out and in again, neither when the user I give the quota does.

This is only possible if you have the latest ownCloud + have read the document above.


#5

yes I’ve read that document (several times) and many posts along the same lines as my issue.
when you change the quota for your LDAP user is the value updated in oc.preferences?
userid = (username)
appid = files
configkey = quota
configvalue = (new value)

thanks


#6

No, but in oc_accounts.

|  4 | NULL                         | 
user1         | 
user1         | 
user1 user1   | 10 GB | 1535555701 | OCA\User_LDAP\User_Proxy | /var/www/owncloud/data/user1         |     1 |

#7

yes I also see the value for quota in oc_accounts for the user updated to the value that I’ve changed in the admin webpage. And that value will remain at the new quota until the user logs in in or a client syncs, then the value in oc_accounts is replaced with the value from oc_preferences (the previous value). Do you think this is something “left behind” by one of the upgrade processes (we have been using owncloud since version 8)
| id | email | user_id | lower_user_id | display_name | quota | last_login | backend | home
9 | user email | Test User | test_user | Test User | 51 GB | 1506799890 | OCA\User_LDAP\User_Proxy | /data/Test_User


#8

That’s weird. Did not happen on my instance, but mine is a fresh 10.0.9.

Could be an remnant of the upgrade process.

Do you have a test instance where you can setup a fresh 10.0.9 and see if the behavior is the same?

You also could set the quota on your LDAP server :slight_smile:


#9

thanks (I think I need to reinstate the test set-up) I can also play around with my (normal user) account removing values entirely from oc_preferences to see what happens.

small cog in a big wheel, so I do not have the ability to change anything in the corporate AD :frowning: (probably a good thing! :wink: )

and at least in this case, I now know how to set a new user quota, not something we need to do much.

thanks again


#10

I’ll also add there are other values in oc_preferences that overwrite values in oc_accounts like “last_login” this updates if I login to the web, but is overwritten when the client syncs by the configvalue in oc_preferences that goes with configkey “lastLogin”. so it looks like my lastlogin was september 2017
If I remove the rows from oc_preferences, relating to quota and lastLogin they don’t re-appear (and setting quota works as it should!). I’m assuming where these values were stored/read from has changed over the versions?


#11

Hey,

the last login topic reminds me at this thread:


#12

indeed,running

occ user:sync “OCA\User_LDAP\User_Proxy”

cleared up the issues with old entries in oc_preferences for lastLogin and quota


#13

Hi,

@ [mudshark]

Sorry but I’m not really expirementent with OwnCloud so can you give us detailed step to solve the problem please.

What sould we do?

Thanks for your answer


#14

run this on your command line:

sudo -u www-data php occ user:sync “OCA\User_LDAP\User_Proxy” -m remove


#15

Thanks for the answer Dmitry

Does running this command impact the actual user which are using default quota. I mean, If they have 2GB quota as default, will it remain at 2GB.

I’m asking this question to understand the potential impact on production as many users are using it.


#16

Cristian,
if your issue was the same as mine (LDAP users quotas getting reset because I’d been upgrading owncloud for a number of years and the database tables/design changed over the versions) then Dmitry’s answer will fix the issue of not being able to set the quota.

If however it’s a different issue then it may not, FWIW when I ran the command all quotas remains where they were set at the time I ran the command.

If the quota is actually coming from AD then this will have no effect
Is my understanding


#17

I would like to say a Big thankyou to Dmitry for his help, my problem is now solved.
Thanks also to Mudshark for the clarification.

NB: Remembre to launch the following command with root access and from the owncloud directory where the config file is present:

sudo -u www-data php occ user:sync "OCA\User_LDAP\User_Proxy" -m

Best regards


#18

Hi all. I have to thanks to all on this topic cause this was the only way I solved my problem.

I post here the link to the OCC comand howto because, in my case (10.0.10 stable) the comand given by Cristian_Santangelo didn’t worked. My config uses a AD group to authenticate only, the quotas are set in the GUI users page. I had one LDAP user that every time he relogon or the syncapp reconnects the quota where reseted to previous value.

See this OCC command guide here: https://doc.owncloud.com/server/admin_manual/configuration/server/occ_command.html#user-commands

My shot was the sudo -u www-data ./occ user:sync “OCA\User_LDAP\User_Proxy” . The system asked what to do with eventual unknown users and I entered ask later.

Thanks a lot.