As I do have 2 different servers in use (both same SW release, but different Account provider) I could see now the difference. That one with Account provider: OpenLDAP works pretty well as supposed - thanks @davidep for supporting and submitting the patches!
It’s just my guess that the Account Provider makes the big differnce - the non working is shown here:
The green accounts I can change on custom mail quota and results are displayed well. The red one I can not change. I can not see any difference between red and green accounts (I did not try all accounts yet).
The blue account was created by using the command: sudo doveadm quota recalc -u ds
and now I can not remove it from the view any more!
Pls help, try to verify if quota display works on your samba AD machine!
Thanks!
I tried.
If I create a quota on an existing user user01, it works properly
If I imposed a domain quota and it works properly.
If I create another user (user02) with quota, not work correctly but holds the domain quota.
If I run
db accounts getprop usr2@mydomain.com MailQuotaCustom
the value is correct
the problem seems to occur with users created after setting the domain quota.
Removing it does not change the situation
Thanks for your cross check @enzoturri ! I created users after I set a domain quota - this is the normal situation, because users are added over the time. Now I understand why some are OK and the new ones not.
If I run this:
[root@dc2 ~]# db accounts getprop ds@intern.org MailQuotaCustom
100
[root@dc2 ~]# db accounts getprop es@intern.org MailQuotaCustom
10
[root@dc2 ~]# db accounts getprop test@intern.org MailQuotaCustom
20
[root@dc2 ~]#
the values are correct, too. (n*100MB).
So we have a situation where this bug can be reproduced.
Which account provider was active in your server? Is this bug really bound to Account provider Samba Active Directory?
I created a virtual machine only to verify the problem. Not having a test domain server, I used openldap.
The size of the quotas, I checked on the web interface and Sogo
I didn’t test it, but I agree with @enzoturri: the bug should be independent from the account provider.
Just added to the todo list, we will look to it next days.