Mail: new accounts having authentication problems
I've not tweaked my ISPConfg setup for a while because everything has been working beautifully. :)
Until today :(
I've set up a new domain and added the mail domain and added two mailboxes.
The web domain works fine (theerfore DNS is good)
But the email boxes cannot be reached - they fail authorization.
All other domains/mailboxes are working correctly.
I've upgraded my ISPConfig to 22.214.171.124. Hasn't helped.
Dovecot version is 1.2.17
Centos version 5.7(final)
Permissions in /var/vmail/ all look correct.
Where do I go from here?
additional info: mail log reports
permission denied + the vmail users dir
missing +x perm
but the permissions ARE correct.
sieve: failed to stat user's sieve script:
What's the output of ls -la /var/mail/? Is SELinux disabled?
Can you post the exact error messages from your mail log?
Ok seems to be solved.
After the mail authentication problems, i found DNS on my various websites started to fail. To test the sites I set up dns in my local hosts file and found the sites were okay. Then I noticed some odd things gong on with MySQL. Further testing found "describe <tables>" command came back with a SQL error saying unable to write to /tmp/#sql...
So I checked permissions on /tmp = 755
Changed permissions on /tmp to 777 and all problems solved.
Is 777 correct for tmp folder?
If so what changed it?
If not, what else could have changed to require this?
Thanks for the confirmation Falko.
Last night, it was reset again to 700!
This has a variety of effects on services. Quite apart from the services that use the tmp directory directly, MySQL uses it for some operations, so any service that uses MySQL can show odd behaviour.
On monday some DNS requests were going astray.
This morning I found mail was stacking up in the mailqueue.
After reseting the tmp folder to 777, I then flushed the mailqueue and everything is back to normal.
Any ideas how or why the /tmp folder permissions are getting reset?
Last night the permissions for /tmp got reset again this time to 750?
What is going on?
Did you check your cron jobs? Also check /etc/cron.daily/.
I've checked all cron jobs. Can't find anything that would do this.
...and it is still happening. (I've now created a cronjob to reset it to 777)
Apart from the ISPConfig cron jobs, I have a yum update running every night.
I also have another server pulling a backup off the server using RSYNC, but thats been running for many months without a problem.
i have same problem when creating new mailbox
/tmp has 777
when i execute
chmod -R +x /var/vmail
i can login in the mailbox
here is my logfile:
Jan 13 08:48:50 ISPMAIL1 dovecot: deliver(email@example.com): chdir(/var/vmail/rr.at/rr) failed: Permission denied
Jan 13 08:48:50 ISPMAIL1 dovecot: deliver(firstname.lastname@example.org): sieve: stat(/var/vmail/rr.at/rr/.sieve) failed: Permission denied (using global script path in stead)
Jan 13 08:48:50 ISPMAIL1 dovecot: deliver(email@example.com): stat(/var/vmail/rr.at/rr/Maildir) failed: Permission denied
Jan 13 08:48:50 ISPMAIL1 dovecot: deliver(firstname.lastname@example.org): stat(/var/vmail/rr.at/rr/Maildir/tmp) failed: Permission denied (euid=5000(vmail) egid=5000(vmail) missing +x perm: /var/vmail/rr.at)
Jan 13 08:48:50 ISPMAIL1 dovecot: deliver(email@example.com): msgid=<20120112172902.50D33A1EAC@ISPMAIL1>: save failed to INBOX: Internal error occurred. Refer to server log for more information. [2012-01-13 08:48:50]
|All times are GMT +2. The time now is 21:13.|
Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.