# [courier-imap-4.5.0] mailbox owner mismatch

## mariourk

I just upgraded net-mail/courier-imap to version 4.5.0.

After restarting courier-imap, I got there errors in my logs:

```

Account's mailbox directory is not owned by the correct uid or gid

```

Obviously, I was unable to access my mailbox via IMAP or IMAP-SSL.

After some Googleling, I found a solution here. As suggested there, I added this line to /etc/courier-imap/imapd:

```

IMAP_MAILBOX_SANITY_CHECK=0

```

Afer restating courier-imap, everything worked fine again. So, for now I'm out of trouble. However, I'm not comfortable with this solution.

Perhaps someone can explain what actually went wrong and how it can be fixed properly?

Thanks!  :Very Happy: 

----------

## Philippe23

I had the same issues.

I found this blog entry that says along the same lines as your link, except he says he did a chgrp -R users .maildir and everything was fine.

The only thing is that I don't know why he chose "users".  Half my .maildir contents are the user's unique group (user "foo" has half his .maildir entries group set to "foo").  Why aren't I doing a chgrp -R foo_user .maildir?

I'm not comfortable with his solution either; can anyone explain this further so I can figure out what I should really do?

(I'm half afraid that Pine, SquirrelMail, or something will create a new folder with the wrong permissions in there on me still....)

----------

## mariourk

The uid and the gid of all the maildirs are set to username:users (recursive). But still courier keeps insisting:

```

Account's mailbox directory is not owned by the correct uid or gid

```

As soon as I set IMAP_MAILBOX_SANITY_CHECK back to 0, everithing works fine again.

I'm really confused why I can't use this fearure  :Confused: 

----------

## Philippe23

I changed some of my .maildir folders to username:users (like you) but hadn't turned back on the SANITY check.  I noticed that a few hours later .maildir/courierimapuiddb had been switched back to username:username -- I'm wondering if (for me/us) he's wrong about which group it is.  Maybe we should be setting them all to username:username.

I might try that.  I didn't yesterday because I didn't want to interrupt anybody's e-mail access on my machine.

----------

## Philippe23

Yeah, that seemed to fix it for my account.

You know how useradd has that -G flag for adding additional groups and a separate flag -g for some "initial login group"?  I bet the account has to be set to use the initial login group (which, at least on  my system) is the user's personal group (same name as username).  I bet on his system it's users.  (I think the group I'm referencing is the one with the GID specified in /etc/passwd for the user.)

Now I just have to fix all the other accounts on my machine.

----------

## Philippe23

So I went back and changed the permissions to username:username for all accounts on my machine, turned back on the SANITY_CHECK and it's been running for a day or two without getting upset.

To summarize what I did (which is a very manual processes):

 Ran find / -type d -iname .maildir as root to find all the maildir folders.  All of mine were in /home/.

 for all folders found (which is to say, in my case, for all user-folders in /home/) Ran grep username /etc/passwd to get the user's gid.  There is probably a better/more correct way to do this, but this is what I could think of.  The gid is the 2nd # listed and you should only get back one line per grep.

Ran grep gid /etc/group to verify that the gid mapped to the user's personal group.  (for me it always did.)

Ran sudo chgrp -R username /home/username/.maildir to change the group to the user's primary group.  username == personal group as verified by my previous step and personal group == user's primary group as verified by the step before that.

 Turned back on the SANITY_CHECK and restarted the daemon.

 watched the logs for a little while especially as I sent a message.

Someone with some brains could probably script that, but I have about 15 users and it was easier to just do it by hand rather than try to figure out sed and trouble shoot a script.

----------

