Error on Sogo when accessing parent of shared mailboxes


(Thorsten) #1

Dear all,

I found some minor strange behavior which I consider as a bug. Maybe it is just some kind of user error either. However, I am not shure if I set up correctly or if I can influence at all. Feel free to move / delete this topic if related to user error :slight_smile:

When opening a shared folder within SOGo, I get the following error message:

“Communication Error with e-mail server”

However, browsing to any of the created shared mailbox subfolders, the error does not occur:

It seems there are some insuffcient right on “shared folders”

Expected behaviour:
Rights should be set correctly when “shared folders” are created within eMail adresses module

TIA for considering

(Markus Neuberger) #2

It’s a permission problem, when I give admin rights to the public folder for user markus I don’t get the error anymore for this user.

/etc/e-smith/events/actions/nethserver-mail-shrmbx-modify ev 'Public' 'Public' user=markus@$(hostname -d) ADMIN

I found another thread with similar issue:

(Michael Träumner) #3

Hi Markus,
I don’t use mail. What are the permissions of the subfolders which work, do they also have admin rights?

@giacomo Couldn’t you set the permissions by creating the box

(Giacomo Sanchietti) #4

No you can’t, since “Public” is like a namespace and it doesn’t contain real mail.
Even TB raises an error if you select the “Public”.

IIMHO, I don’t see this a bug.

(Markus Neuberger) #5

They have no acls and just work but this is not possible for the root folder “Public”.
By default the Public folder has lookup right for authenticated users. If you add the “read” right, there’s no error anymore in SOGo.

doveadm acl set -u markus@cmb.local Public authenticated lookup read

That’s right. In TB it’s not working even when you set all rights for Public. As you wrote, it seems TB expects a mailbox and not a namespace. But at least for SOGo it could be fixed.

(Giacomo Sanchietti) #6

I wouldn’t change the server behavior for a client misbehavior :slight_smile:

(Thorsten) #7

Please imagine somebody we in Germany call a DAU. DAU means “Dümmster anzunehmender User” or in English “Presumably most stupid user”. …

Please consider the fact that most of my users do not even understand the difference between server and client. For them, SOGo is not a client provided by a sever, it is service they use … OK and a ‘service’ has got something to do with server. Consequently, SOGo is a server … Oh… and my Admin is responsible for the server … He needs to take care of “that I do not even see an error or he has done bad job I need to complain about with my boss …”

In short words: Form nethservers users (and some admin) point of view, this is a servers misbehavior :slight_smile:

(Mark Verlinde) #8

Well, I think it is a bit of both or at least a mismatch between dovecot and SOGo.

Looking at this thread and similar problems @redmail and @mailcow the root cause seems we have to configure SOGo to find the incoming-mail in the root of a user folder. As a consequence SOGo does this for namespaces too, it still expects - wrongly - items in the root of namespace.

Will try to find out if this is true…

Unfortunately did not find a solution. EDIT other than @mrmarkuz found (see below)

(Markus Neuberger) #9

doveadm acl set -A Public authenticated lookup read

does solve the SOGo error.

SOGo expects “read” right and dovecot doesn’t provide it so it’s really hard to say if it’s server or client misbehavior. For TB it’s definitely a clients misbehavior.

But changing rights on the server may affect other clients. Maybe another client uses the “read” right for making folders visible which may not be wanted.

(Thorsten) #10

You mean that the same error would be eliminated within Thunderbird, too? Cool! :innocent::nerd_face:

(Thorsten) #11

Users NOT assigned to this shared Mailbox Do see the “Shared Mailbox Parent folder” as well as the the “shared foldests” itself, however such users can not access any of them.

(Giacomo Sanchietti) #12

To recap: some clients misbehave when trying to access the “Public” namespace and raise an error like “Mailbox doesn’t exists Public/Public” (on TB).

A possible solution from @mrmarkuz is to set the following acl:

doveadm acl set -A Public authenticated lookup read

I don’t know if such modification can break something else.
Calling the experts now: @davidep @filippo_carletti do you think this is a good workaround?

(Thorsten) #13

Hi @giacomo,

here is the error message from TB, sorry for german.


Translation (approximately):
The current step “Public” failed. The server of account “thorsten@…” responded: [NOPERM]: Permission denied.