Skip to main content

[CPANEL-26448] Default Email Account Showing Incorrect Usage

DarkxPunk
Hi there, In one of the accounts on my server I noticed the default account showing high usage. I checked the webmail, everything is empty, I also tell mail to be rejected rather than collect if no email address exists. Now upon further investigation I noticed this: - Removed - For some reason one of the domains mailbox usage (or I assume that's what it is) is being displayed as being apart of the default account. No idea where to start. Thanks for the help!

Comments

52 comments

Date Votes
  • cPanelLauren
    Hello, Today v82 of cPanel was moved to RELEASE and this case is marked as resolved in v82. You can see this in our changelogs here: 82 Change Log - Change Logs - cPanel Documentation Please let us know if you have any further issues with this.
    0
  • whipworks
    Hi @cPanelLauren, We cleared the emails on the default account. But the size is still there. We're going to check again in a couple of hours. Maybe it takes time, but I don't know. Also, the update still didn't fix the way CPanel reads the total quota calculation. Like for example, we have this one account that is set for 4500MB of space, but the total email size the account has is 6000MB. Technically, the account shouldn't be working because it's over quota. So it looks like this..... Quota set to 4500MB Quota being used is 4000MB But when you log into the cpanel account and check Disk Usage, the quota is all allocated to the /mail side with 5999MB. So it doesn't match.
    0
  • cPanelLauren
    Hi @whipworks If you're using maildir (not mdbox) for your storage of emails can you run the following:
    /scripts/generate_maildirsize --confirm --allaccounts --verbose $USER
    Then tell me if the issue persists?
    0
  • whipworks
    Our network admin ran the script and got errors. I sent the error message through PM. Kindly check please. Thank you.
    0
  • cPanelLauren
    Hi @whipworks Thanks for sending that output though next time you can send the same thing through the forums just replace any identifying information. markm@, artr@, and iand@ were accounts that were marked as not existing - do these email accounts exist? You could run the following to get a quick list: api --user=$user Email list_pop
    0
  • whipworks
    Hi @whipworks Thanks for sending that output though next time you can send the same thing through the forums just replace any identifying information. markm@, artr@, and iand@ were accounts that were marked as not existing - do these email accounts exist? You could run the following to get a quick list: api --user=$user Email list_pop

    Hi Lauren, Sorry if I had to PM the error. A bit long and too much stuff to edit. Need a resolution for this one. To answer your question.... Yes and No. That's another problem we've encountered. The only account that's suppose to exist were info@ and artr@. But artr@ is no where to be found. We can't even retrieve it. And when we try to re-create the email account, the server would just give us an error that it already exist. So that's another issue that needs to be fixed.
    0
  • cPanelLauren
    Hello, My assumption is that remnants of the accounts exist in the mail directory. That would explain why non-existing accounts are being flagged in this instance. If you'll notice the one account that should exist info@ didn't have any errors. For the accounts that aren't supposed to exist you'd want to remove the folders associated with them. You might take this approach for the account that should exist but doesn't if you don't need the mail.
    0
  • whipworks
    Hi, All is true except for info@ and artr@. So with the others showing errors, we can remove those folders like you mentioned, but artr@ should be there, which is not. And we cannot re-create it because of the said error that it already exist even if we don't see it on the Email Accounts list.
    0
  • cPanelLauren
    Hi, All is true except for info@ and artr@. So with the others showing errors, we can remove those folders like you mentioned, but artr@ should be there, which is not. And we cannot re-create it because of the said error that it already exist even if we don't see it on the Email Accounts list.

    Technically because there is an issue with the artr account displaying - it doesn't exist. The issue for both the artr account and the other accounts which have errors is due to remnants of the accounts being present in the mail directory. I'll detail the steps I might take to resolve this again: 1. For the artr account
    • If you need the mail within that account's folders on the server I would attempt to create a dummy account (something you can remove later) and the update to the json file may bring the artr@ account back (let me know if you try this and it does not work)
    • If you do not not need the data remaining for that account on the server I would suggest removing any associated files/folders just as you would for the accounts that no longer exist.
    2. For the markm@ iand@ accounts which should not exist - you need to remove the data that is present within the mail directory associated with these accounts Once these are completed I would suggest re-running the generate maildirsize script.
    0
  • whipworks
    So I've done and remove all folders assocaited with artr@ and it still comes up with the error "account already exist". Oddly enough, when I go back to File Manager and search artr, a new folder pops up. So it looks like it creates the account still even if it gives the error, but it still won't show up on the Email Accounts list.
    0
  • cPanelLauren
    @whipworks At this point, I'd recommend opening a ticket using the link in my signature. Once open please reply with the Ticket ID here so that we can update this thread with the resolution once the ticket is resolved. Thanks!
    0
  • whipworks
    Support Request ID is: 13273529
    0
  • cPanelLauren
    Hi @whipworks Thanks! I checked in on that ticket today and added some notes summarizing what we went over here. I'll continue checking on it and update here when there is any new information. Thanks!
    0
  • 4u123
    This issue may possibly no longer happen on new accounts due to it supposedly being fixed - but what about existing accounts? I'd say pretty much all of our users have this problem currently. Is there a way to run /scripts/generate_maildirsize on all users?
    0
  • cPanelLauren
    Based on the case comments it shouldn't continue to be an issue for users: [QUOTE] Ignore virtual user mailboxes when processing system user quotas. Case CPANEL-26448: The system user for each cPanel account was showing the cumulative total of all it's virtual accounts disk usage. This commit fixes that by adding a quota rule to ignore it's virtual user's inboxes. This change also moves the account type data into the user_info returned by Cpanel::AcctUtils::Lookup::MailUser, and returns service auth user lookups as the account type "serviceauth". Changelog: Don't apply virtual mailbox disk usage to the cPanel system user's disk usage.
    I believe a Dovecot quota_rule was added in this instance which would affect all accounts
    Is there a way to run /scripts/generate_maildirsize on all users?

    There isn't a way to do this without using a loop something like this bash script might work? #!/bin/bash IFS="$" cd /var/cpanel/users find . -type 'f' | while read CPUSER; do echo "Now processing ${CPUSER} ..." /scripts/generate_maildirsize --allaccounts --verbose --confirm ${CPUSER} done
    IF you do use this or something like it don't forget to run chmod +x filename
    once the file is created or you'll not be able to run it.
    0
  • 4u123
    Ok thanks. It's definitely not fixed for us in terms of existing users. All servers show this behaviour, but we will run the command in a loop as suggested which will hopefully resolve this for good.
    0
  • Metro2
    It's definitely not fixed for us in terms of existing users.

    Same here :(
    0
  • cPanelLauren
    Nope, it's not. This case is solved though. There's a new one here:
    0
  • Metro2
    Nope, it's not. This case is solved though. There's a new one here:
    0
  • cPanelLauren
    Thank you Lauren. I'm not normally "cranky" on the forums here, but I can't help but shake my head in disbelief that this thread is marked "solved" when it never has been for me. I appreciate you being on top and aware of the "new" version of the same thing though.

    I get that completely, to clarify, I'm marking the case as solved, to match with the internal case status. We are currently on the 3rd internal case for this the prior were marked either cannot replicate or solved. This way we're tracking the right case and keeping the most relevant details. My personal belief is that the issue itself has not been solved for everyone even once, but I have to keep things straight if I'm going to provide you with the best and most relevant information and give accurate updates. So for transparency sake, my steps are: Tag the thread with the case when I can associate a thread with one Mark thread as in progress until the case is ready for a build When ready for a build mark as pending publication When in a release version of cPanel/WHM or When the case is marked as done - The thread is marked as solved. If an issue pops up again with the same issue like in this instance I'll usually note in the new thread - which I did do in this instance.
    0
  • imrans
    Hello, is there any updates on this as I am facing the same issue here . all above command and scripts tried. Thank you
    0
  • cPanelLauren
    Please defer all comments to the relevant thread. Marking this thread as closed to keep comments to the correct place.
    There's a new one here:
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post