Re: Permission denied UNIX perms appear ok (ACL/MAC wrong?))
There are a number of issues that can appear to be ACL issues when in fact
its something else.
As other's have mentioned, AppArmor profiles and SELinux contexts can be
checked and are the most common. There are ACL permissions as well if you
enabled ACL (they are not enabled by default on Ubuntu server).
I've occasionally (rarely) seen some weird interactions with sockets
between MDA and MTA if the permissions on the directory were not set
correctly.
Additionally, if a mount permission mask is being used, that can
occasionally cause similar issues as well, as is often the case with using
an NTFS backing filesystem for maildir that's been mounted with unix perms.
There can also be some edge-cases with permissions in Ubuntu's flavored
snap containers as well as docker containers and custom sieves.
Its difficult to say with any accuracy what is causing your issue with the
information provided.
Have you increased the verbosity of the logging?
If all of the normal culprits do not stand out, maybe some others will have
an idea.
As a final fallback you can always set a breakpoint and use a reverse
debugger. Its not going to be performant but it will at least narrow down
where the issue is coming from, and what the intermediate states were that
led to the error so you can save/replicate them moving forward for
resolution. Non-determinism can creep into code in a lot of different ways.
Best Regards,
N
On Tue, Aug 23, 2022 at 4:53 AM Austin Witmer
wrote:
> Here is the output of dovecot -n
>
> *austin@mail*:*~*$ doveconf -n
> # 2.3.16 (7e2e900c1a): /etc/dovecot/dovecot.conf
> # Pigeonhole version 0.5.16 (09c29328)
> # OS: Linux 5.15.0-46-generic x86_64 Ubuntu 22.04.1 LTS
> # Hostname: mail
> auth_mechanisms = plain login
> listen = *
> mail_location = mbox:~/mail:INBOX=/var/mail/%u
> mail_privileged_group = mail
> managesieve_notify_capability = mailto
> managesieve_sieve_capability = fileinto reject envelope encoded-character
> vacation subaddress comparator-i;ascii-numeric relational regex imap4flags
> copy include variables body enotify environment mailbox date index ihave
> duplicate mime foreverypart extracttext
> namespace inbox {
> inbox = yes
> location =
> mailbox Drafts {
> special_use = \Drafts
> }
> mailbox Junk {
> special_use = \Junk
> }
> mailbox Sent {
> auto = subscribe
> special_use = \Sent
> }
> mailbox "Sent Messages" {
> special_use = \Sent
> }
> mailbox Spam {
> auto = subscribe
> }
> mailbox Trash {
> auto = subscribe
> special_use = \Trash
> }
> prefix =
> }
> passdb {
> driver = pam
> }
> passdb {
> args = /etc/dovecot/dovecot-sql.conf
> driver = sql
> }
> passdb {
> args = /etc/dovecot/dovecot-sql.conf
> driver = sql
> }
> plugin {
> sieve =
> file:/mnt/volume1/mailserver/plain/sieve/%d/%n/scripts;active=/mnt/volume1/mailserver/plain/sieve/%d/%n/%n.sieve
> sieve_before = /var/lib/dovecot/sieve/
> sieve_global_dir = /var/lib/dovecot/sieve/
> sieve_global_path = /var/lib/dovecot/sieve/default.sieve
> sieve_user_log =
> file:/mnt/volume1/mailserver/plain/sieve/%d/%n/sieve_error.log
> }
> protocols = imap lmtp pop3 imap lmtp sieve pop3
> service auth {
> unix_listener /var/spool/postfix/private/auth {
> group = postfix
> mode = 0660
> user = postfix
> }
> }
> service imap-login {
> inet_listener imap {
> port = 0
> }
> inet_listener imaps {
> port = 993
> }
> }
> service lmtp {
> unix_listener /var/spool/postfix/private/dovecot-lmtp {
> group = postfix
> mode = 0600
> user = postfix
> }
> }
> service managesieve-login {
> inet_listener sieve {
> port = 4190
> }
> service_count = 1
> }
> ssl = required
> ssl_cert = ssl_dh = # hidden, use -P to show it
> ssl_key = # hidden, use -P to show it
> ssl_prefer_server_ciphers = yes
> userdb {
> driver = passwd
> }
> userdb {
> driver = prefetch
> }
> userdb {
> args = /etc/dovecot/dovecot-sql.conf
> driver = sql
> }
> userdb {
> driver = prefetch
> }
> userdb {
> args = /etc/dovecot/dovecot-sql.conf
> driver = sql
> }
> protocol lmtp {
> hostname = mail.mydomain.com
> mail_plugins = " sieve"
> postmaster_address = postmas...@mydomain.com
> }
> protocol lda {
> mail_plugins = " sieve"
> }
>
>
> Austin Witmer
>
>
> On Aug 20, 2022, at 12:09 PM, Austin Witmer
> wrote:
>
> And no, I don’t think I am using ACL’s.
>
> getfacl austin /mnt/volume1/mailserver/plain/maildir/
> getfacl: austin: No such file or directory
> getfacl: Removing leading '/' from absolute path names
> # file: mnt/volume1/mailserver/plain/maildir/
> # owner: austin
> # group: austin
> user::rwx
> group::rwx
> other::r--
>
> Austin Witmer
>
> On Aug 20, 2022, at 11:15 AM, spi wrote:
>
>
>
> Am 20.08.22 um 16:52 schrieb Austin Witmer:
> Hello all!
>
> Recently I upgraded my mail server to Ubuntu 22.04 LTS and ever since
> then I am periodically getting some dovecot errors like the below in
> my mail log. As far as I
Re: Dovecot/MSQL issue
Actually, it seems I may have been wrong in initial assumption that the issue with the client was that it was being identified to mysql as coming from localhost when connecting via tcp. This is what syslog indicated as a reason for the failure but its not the whole picture. As John mentioned I am trying to have dovecot connect over TCP to mysql (not using the socket), and the issue looked like the cause was the identified by portion of mysql being read by either mysql incorrectly or the domain portion being overwritten on dovecot's end (I don't know about the internals enough to say for sure where). Just as due dilligence, I added credentials for a mysql user identified by localhost and removed the jail since the dovecot error was stating that it failed for connection by user@'localhost' (where there weren't credentials). After adding the credentials, I performed all the usual mysql tests before moving testing up to dovecot and still get an auth failure. The log seems to be a bit of a red herring or at the minimum doesn't show the whole picture. Replacing the connection string host with the socket (host=localhost) and everything works, and using an external IP that's not 127.0.0.1 works as expected as well. (confirmed by standing up two isolated mysql and dovecot containers and setting auth up over the bridge). If the issue was caused by user@'localhost' creating the credentials should have resolved it, and it didn't. So something weird is going on. I've got the environment built up in a dockerfile I can provide if anyone wants to dig into what's causing it. In the meantime due to time constraints, I'll just be working with the socket file from now for hosts running most of the mail stack all in one. Best Regards, Lorek. On Sun, Jun 30, 2019 at 10:09 PM John Fawcett via dovecot < dovecot@dovecot.org> wrote: > On 30/06/2019 13:36, Aki Tuomi via dovecot wrote: > >> > >> Hello, I'm trying to work through an issue that cropped up on a server > I've been working on and haven't found a very good workaround. > >> > >> Dovecot is operating in a jailed environment. > >> > >> The configuration in dovecot-sql.conf.ext has been set appropriately > with the host=127.0.0.1 (which works from a jailed environment) and when > dovecot attempts to auth it appears to perform a reverse dns lookup and > overwrites the host with the result localhost before using the msql > credentials 'user'@'localhost' which then fails after timing out. > >> > >> I'm currently running version 2.2.33.2 of dovecot. > >> > >> The workaround seems to be to have two credentials for the same user. > >> 'user@'localhost' and 'user'@'127.0.0.1'; > >> postfix operates in a jail as well and works around the jail issue in > the same way but doesn't overwrite the specified host with a reverse dns > lookup. > >> > >> Anyone have any suggestions on how to handle this issue better? or > maybe there's a way to force different behavior which I haven't yet found > in the documentation? > >> > >> Any help is much appreciated. > >> > >> Best Regards. > > Hi! > > > > The 127.0.0.1 issue is actually a MySQL issue, unfortunately. > > > > " On Unix, MySQL programs treat the host name localhost specially, in a > way that is likely different from what you expect compared to other > network-based programs: the client connects using a Unix socket file. The > --socket option or the MYSQL_UNIX_PORT environment variable may be used to > specify the socket name. " > > > > So not really something we could do much about. > > > > Aki > > Aki > > it is possible to force the use of tcp socket instead of unix socket by > specifying an ip instead of the hostname localhost. As I understood it > Nathan is specifying 127.0.0.1 so that will connect with tcp socket. > > John > >
Re: Dovecot/MSQL issue
John, I was having an issue with the tcp socket @ 127.0.0.1. I'd tried various different modifications based on the logs and the issue had remained regardless. I had built up the environment in a dockerfile and worked on it through the weekend so the problem was replicable across instances up until this morning. I ended up switching over to using the socket yesterday and only checked out to the previous commit this morning to run a few additional tests on the problematic part. For whatever reason, the issue is now completely gone. At this point, I'm thinking this must be a docker issue. The only notable (minor) differences between this past weekend and today are an AER/ASPM kernel error that was logging on the host. The paste is here: https://pastebin.com/idBWKDq2 The main difference between the weekend and today is the additional line included saying it can't find device of ID 0008. That wasn't showing up over the weekend. I think given this experience I may have to revisit my testing methodology when working with docker. Best Regards, Lorek On Tue, Jul 2, 2019 at 12:38 PM John Fawcett via dovecot < dovecot@dovecot.org> wrote: > On 01/07/2019 09:48, lorek via dovecot wrote: > > Actually, it seems I may have been wrong in initial assumption that > > the issue with the client was that it was being identified to mysql as > > coming from localhost when connecting via tcp. > > This is what syslog indicated as a reason for the failure but its not > > the whole picture. > > > > As John mentioned I am trying to have dovecot connect over TCP to > > mysql (not using the socket), and the issue looked like the cause was > > the identified by portion of mysql being read by either mysql > > incorrectly or the domain portion being overwritten on dovecot's end > > (I don't know about the internals enough to say for sure where). > > > > Just as due dilligence, I added credentials for a mysql user > > identified by localhost and removed the jail since the dovecot error > > was stating that it failed for connection by user@'localhost' (where > > there weren't credentials). > > After adding the credentials, I performed all the usual mysql tests > > before moving testing up to dovecot and still get an auth failure. The > > log seems to be a bit of a red herring or at the minimum doesn't show > > the whole picture. > > > > Replacing the connection string host with the socket (host=localhost) > > and everything works, and using an external IP that's not 127.0.0.1 > > works as expected as well. (confirmed by standing up two isolated > > mysql and dovecot containers and setting auth up over the bridge). > > > > If the issue was caused by user@'localhost' creating the credentials > > should have resolved it, and it didn't. So something weird is going on. > > I've got the environment built up in a dockerfile I can provide if > > anyone wants to dig into what's causing it. > > > > In the meantime due to time constraints, I'll just be working with the > > socket file from now for hosts running most of the mail stack all in one. > > > > Best Regards, > > Lorek. > > Lorek > > If you have user@localhost as a user in mysql you will be able to > connect with either of these options: > > - a tcp socket via an ip address that resolves to localhost > > - a unix socket via hostname localhost. > > If you have user@127.0.0.1 as a user in mysql you will be able to > connect only via: > > - a tcp socket using ip address 127.0.0.1. > > John > > >
