...and check permissions on *all* the directories in the path leading to the
lockfile for proper access (at least eXecute permission) and no conflicting
ACLs
(as viktor already wrote).
--tmolitor
Am Freitag, 11. Oktober 2019, 15:00:36 CEST schrieb Viktor Dukhovni:
> Reboot your system, and try again.
>
> > On Oct 11, 2019, at 2:49 PM, Fazzina, Angelo <angelo.fazz...@uconn.edu>
> > wrote:
> >
> > Hi, thanks for the tip about checking SELINUX. Sadly no change when
> > testing openssl command with SELINUX off.
> TLS has nothing to with this. The SMTP server is unable to
> lock a file that is used to avoid waking up all the SMTP
> listeners every time a new connection arrives. The lock
> file ensures that only listener is waiting to accept new
> connections at a time.
>
> The EPERM error is not normal in this context. On my
> system:
>
> $ ls -ld /var/spool/postfix{,/pid{,/inet.smtp}}
> drwxr-xr-x 16 root wheel 16 Aug 4 22:46 /var/spool/postfix
> drwxr-xr-x 2 root postfix 19 Apr 18 04:43 /var/spool/postfix/pid
> -rw------- 1 root postfix 0 Feb 19 2017
> /var/spool/postfix/pid/inet.smtp
>
> which shows that only root can open the lock file, and yet
> there are no issues with the lock, because Postfix opens
> the file before dropping privs. So if you're seeing EPERM,
> your system is either configured with additional security
> restrictions, or has become confused and needs a reboot.
>
> Also, make sure there are no additional extended ACLs on the file,
> immutable bits, ... Good luck.
>
> Don't waste time with TLS, that's entirely irrelevant.
