Re: [Dovecot] ot: identifying TB IMAP issues
Hij Voytek, if the connection becomes stale, it might well be a network-related or client-side issue. Have you ever heard of the ADSL MTU problem? If some router/firewall inbetween drops ICMP messages related to path-MTU-discovery, then the maximum transfer unit (MTU) might be wrong and larger packets might get dropped on their way which makes the TCP connection become stale. The user's TCP segments need to be small enough so that a PPPoE header (8 Bytes) can be added to the packets without exceeding the default network MTU of 1500 Bytes, so the maximum recommnded TCP segment size for ADSL users is 1492 Bytes. Read more about the maximum segment size (MSS) clamping issue here: http://lartc.org/howto/lartc.cookbook.mtu-mss.html Regards Daniel
Re: [Dovecot] Plugin mail-filter tangles
Le 28 mai 2014 à 16:41, Stanislas SABATIER a écrit : > [...] > I tried to explain my specific case in my first post to the list (first > mail of this thread, may 24) : > [...] > To sum up, here are the headers : (CASE 1) > >*from : user1@mydomain1* >to: some...@yahoo.com >CC: user2@mydomain2, user3@mydomaine3 > > > In this specific situation, Dovecot receives one email from Postfix for > user2 and user3. Dovecot is creating two user contexts, load mail-filter > plugin with user2 params, it saves the email, then it loads mail-filter > plugin with user3 params BUT, instead of reading the original email from > Postfix, Dovecot is trying to read the email from user2 (I see an > istream opening in logs) and pass it to user3. That fails because, in > this context, Dovecot can't access user2's email that has been encrypt > by my mail-filter. Hello Stanislas, Indeed, the above describes your intial post. A case I described as being a bit frightening, since it could raise some privacy concerns. > [...] > To sum up, here are the headers : (CASE 2) > >*from : some...@gmail.com* >to : some...@yahoo.com >CC: user2@mydomain2, user3@mydomaine3 > > > In this situation, Dovecot receives one email from Postfix for user2 and > user3 (same situation than case 1). Dovecot is creating two user > contexts, load mail-filter plugin with user2 params, it saves the email, > then it loads mail-filter plugin with user3 params and save the email > with user3 params. And I can say « working perfectly » ! > > [...] And here, you confirm the new info throughout this thread. So, the nature of the envelope sender would have an impact on how an email is delivered by Dovecot's LMTP to local recipients. Up to now, the only path I could find for bringing some confusion among recipients would be in the handling provided by client_input_data_write_local() of src/lmtp/commands.c. Even if the link with the envelope sender still remains obscure to me... Anyway, managing to have Postfix sending one message per recipient might prove useful for diagnosing the problem. HTH, Axel
Re: [Dovecot] Panic: file mail-index-transaction-export.c: line 203 (log_append_ext_hdr_update): assertion failed: (u32.offset + u32.size <= ext_hdr_size)
Unfortunately, I'm still getting the same errors post upgrade to 2.2.13.
I'm coming from 2.1.12, so perhaps there is some slight incompatibility
in some circumstances with the index files? I'm continuing to delete
them as this arises, and so far I've no repeat problem accounts.
Andy
---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---
On 05/30/2014 16:02, Larry Rosenman wrote:
I actually submitted the PR's. I'm waiting for the real maintainer to
approve or for the 2 week timeout.
As I said, it's doing great for me :)
On Fri, May 30, 2014 at 3:01 PM, Andy Dills wrote:
Thanks to the suggestion by Larry off-list, I snagged an official
patch
from the FreeBSD PR and now the ports are compiling cleanly.
I'll report back if I get the errors again.
Thanks,
Andy
---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---
On 05/30/2014 15:34, Andy Dills wrote:
Hi there,
We recently upgraded to 2.2.12 (the current version in FreeBSD's port
tree), and are seeing these errors in our logs (not super frequently,
but it happens):
May 30 13:20:57 mail1 kernel: pid 15752 (imap), uid 1005: exited on
signal 6
May 30 13:20:57 mail1 dovecot: imap(xxx): Fatal: master:
service(imap):
child 15752 killed with signal 6 (core not dumped - set service imap
{
drop_priv_before_exec=yes })
I tried manually upgrading to 2.2.13, on the off chance that was
fixed,
but I couldn't get the new pigeonhole (0.4.3) to compile once I did
(perhaps why the FreeBSD port maintainer hasn't updated yet?).
Suggestions? Right now we just check every couple of hours for
affected
users, and then delete all of the dovecot files for the affected
user,
which ends the error.
Thanks,
Andy
---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---
Re: [Dovecot] Panic: file mail-index-transaction-export.c: line 203 (log_append_ext_hdr_update): assertion failed: (u32.offset + u32.size <= ext_hdr_size)
I actually submitted the PR's. I'm waiting for the real maintainer to
approve or for the 2 week timeout.
As I said, it's doing great for me :)
On Fri, May 30, 2014 at 3:01 PM, Andy Dills wrote:
> Thanks to the suggestion by Larry off-list, I snagged an official patch
> from the FreeBSD PR and now the ports are compiling cleanly.
>
> I'll report back if I get the errors again.
>
>
> Thanks,
> Andy
>
> ---
> Andy Dills
> Xecunet, Inc.
> www.xecu.net
> 301-682-9972
> ---
>
> On 05/30/2014 15:34, Andy Dills wrote:
>
>> Hi there,
>>
>> We recently upgraded to 2.2.12 (the current version in FreeBSD's port
>> tree), and are seeing these errors in our logs (not super frequently,
>> but it happens):
>>
>> May 30 13:20:57 mail1 kernel: pid 15752 (imap), uid 1005: exited on
>> signal 6
>> May 30 13:20:57 mail1 dovecot: imap(xxx): Fatal: master: service(imap):
>> child 15752 killed with signal 6 (core not dumped - set service imap {
>> drop_priv_before_exec=yes })
>>
>> I tried manually upgrading to 2.2.13, on the off chance that was fixed,
>> but I couldn't get the new pigeonhole (0.4.3) to compile once I did
>> (perhaps why the FreeBSD port maintainer hasn't updated yet?).
>>
>> Suggestions? Right now we just check every couple of hours for affected
>> users, and then delete all of the dovecot files for the affected user,
>> which ends the error.
>>
>> Thanks,
>> Andy
>>
>> ---
>>
>> Andy Dills
>> Xecunet, Inc.
>> www.xecu.net
>> 301-682-9972
>> ---
>>
>
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 (c) E-Mail: larry...@gmail.com
US Mail: 108 Turvey Cove, Hutto, TX 78634-5688
Re: [Dovecot] Panic: file mail-index-transaction-export.c: line 203 (log_append_ext_hdr_update): assertion failed: (u32.offset + u32.size <= ext_hdr_size)
Thanks to the suggestion by Larry off-list, I snagged an official patch
from the FreeBSD PR and now the ports are compiling cleanly.
I'll report back if I get the errors again.
Thanks,
Andy
---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---
On 05/30/2014 15:34, Andy Dills wrote:
Hi there,
We recently upgraded to 2.2.12 (the current version in FreeBSD's port
tree), and are seeing these errors in our logs (not super frequently,
but it happens):
May 30 13:20:57 mail1 kernel: pid 15752 (imap), uid 1005: exited on
signal 6
May 30 13:20:57 mail1 dovecot: imap(xxx): Fatal: master: service(imap):
child 15752 killed with signal 6 (core not dumped - set service imap {
drop_priv_before_exec=yes })
I tried manually upgrading to 2.2.13, on the off chance that was fixed,
but I couldn't get the new pigeonhole (0.4.3) to compile once I did
(perhaps why the FreeBSD port maintainer hasn't updated yet?).
Suggestions? Right now we just check every couple of hours for affected
users, and then delete all of the dovecot files for the affected user,
which ends the error.
Thanks,
Andy
---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---
[Dovecot] Panic: file mail-index-transaction-export.c: line 203 (log_append_ext_hdr_update): assertion failed: (u32.offset + u32.size <= ext_hdr_size)
Hi there,
We recently upgraded to 2.2.12 (the current version in FreeBSD's port
tree), and are seeing these errors in our logs (not super frequently,
but it happens):
May 30 13:20:57 mail1 kernel: pid 15752 (imap), uid 1005: exited on
signal 6
May 30 13:20:57 mail1 dovecot: imap(xxx): Fatal: master: service(imap):
child 15752 killed with signal 6 (core not dumped - set service imap {
drop_priv_before_exec=yes })
I tried manually upgrading to 2.2.13, on the off chance that was fixed,
but I couldn't get the new pigeonhole (0.4.3) to compile once I did
(perhaps why the FreeBSD port maintainer hasn't updated yet?).
Suggestions? Right now we just check every couple of hours for affected
users, and then delete all of the dovecot files for the affected user,
which ends the error.
Thanks,
Andy
---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---
[Dovecot] doveadm fts optimize CRASH
thebighonker.lerctr.org /home/ler $ gdb -c doveadm.core `which doveadm` GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Core was generated by `doveadm'. Program terminated with signal 6, Aborted. Reading symbols from /lib/libz.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.6 Reading symbols from /lib/libcrypt.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.5 Reading symbols from /usr/local/lib/dovecot/libdovecot-storage.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/dovecot/libdovecot-storage.so.0 Reading symbols from /usr/local/lib/dovecot/libdovecot.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/dovecot/libdovecot.so.0 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/local/lib/dovecot/lib20_fts_plugin.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/dovecot/lib20_fts_plugin.so Reading symbols from /usr/local/lib/dovecot/lib21_fts_lucene_plugin.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/dovecot/lib21_fts_lucene_plugin.so Reading symbols from /usr/local/lib/libclucene-core.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libclucene-core.so.1 Reading symbols from /usr/local/lib/libclucene-shared.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libclucene-shared.so.1 Reading symbols from /usr/lib/libc++.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libc++.so.1 Reading symbols from /lib/libcxxrt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libcxxrt.so.1 Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /usr/local/lib/dovecot/lib90_stats_plugin.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/dovecot/lib90_stats_plugin.so Reading symbols from /usr/local/lib/dovecot/doveadm/lib10_doveadm_sieve_plugin.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/dovecot/doveadm/lib10_doveadm_sieve_plugin.so Reading symbols from /usr/local/lib/dovecot-2.2-pigeonhole/libdovecot-sieve.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/dovecot-2.2-pigeonhole/libdovecot-sieve.so.0 Reading symbols from /usr/local/lib/dovecot/libdovecot-lda.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/dovecot/libdovecot-lda.so.0 Reading symbols from /usr/local/lib/dovecot/doveadm/lib20_doveadm_fts_lucene_plugin.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/dovecot/doveadm/lib20_doveadm_fts_lucene_plugin.so Reading symbols from /usr/local/lib/dovecot/doveadm/lib20_doveadm_fts_plugin.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/dovecot/doveadm/lib20_doveadm_fts_plugin.so Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0008013cc0da in kill () from /lib/libc.so.7 [New Thread 801c2b800 (LWP 101632/doveadm)] (gdb) bt #0 0x0008013cc0da in kill () from /lib/libc.so.7 #1 0x0008013ca809 in abort () from /lib/libc.so.7 #2 0x000802cf7b39 in __cxa_pure_virtual () from /lib/libcxxrt.so.1 #3 0x0008025159dc in lucene::store::BufferedIndexOutput::~BufferedIndexOutput () from /usr/local/lib/libclucene-core.so.1 #4 0x00080251717a in lucene::store::FSDirectory::FSIndexOutput::FSIndexOutput () from /usr/local/lib/libclucene-core.so.1 #5 0x000802518983 in lucene::store::FSDirectory::createOutput () from /usr/local/lib/libclucene-core.so.1 #6 0x000802544c9d in lucene::index::CompoundFileWriter::close () from /usr/local/lib/libclucene-core.so.1 #7 0x000802558b32 in lucene::index::SegmentMerger::createCompoundFile () from /usr/local/lib/libclucene-core.so.1 #8 0x000802566b2d in lucene::index::IndexWriter::mergeMiddle () from /usr/local/lib/libclucene-core.so.1 #9 0x0008025620f8 in lucene::index::IndexWriter::merge () from /usr/local/lib/libclucene-core.so.1 #10 0x000802527738 in lucene::index::SerialMergeScheduler::merge () from /usr/
[Dovecot] attachment sis + EMLINK (too many links) = segfault bug (2.2.12)
Hi,
we use attachment dedup with lots of emails (still migrating to it
from maildir).
We use netapp storage with wafl filesystem over nfs.
Problem is that netapp has hard limit of 100k hardlinks to one file.
And we encountered it.
Problem is that dovecot start do segfault (lmtp,dsync,pop3 etc) when it
happend when tried to deliver new emails with that attachment.
Here is strace of dsync:
6740
link("/nfsmnt/mailatch1/f9/10/hashes/f9108ddaa156ac15738e41ed3bedec1eda50175d",
"/nfsmnt/mailatch1/f9/10/f9108ddaa156ac15738e41ed3bedec1eda50175d-7bb7a20ddb598853541a28db4a9f")
= -1 EMLINK (Too many links) 6740 --- SIGSEGV (Segmentation fault) @ 0
(0) ---
ls -lh:
-rw--- 10 vmail vmail 4.7K Apr 28
16:54 /nfsmnt/mailatch1/f9/10/hashes/f9108ddaa156ac15738e41ed3bedec1eda50175d
We were using mail_attachment_min_size=4kb, we solve it by increasing it
to 8kb.
It would be nice to somehow fix this problem. Like not crash when
EMLINK happend and maybe do not deduplicate attachments but deliver
email without dedup.
Or create second file in hashes/ and start hardlinking it instead of
original.
AFAIK ext4 has also hard-link limit 64k
(http://en.wikipedia.org/wiki/Hard_link#Limitations_of_hard_links)
So this can happen to anyone with lots of emails.
Thanks
--
[ Ohodnotte kvalitu mailu: http://nicereply.com/websupport/Stano/ ]
Pavel Stano | Troubleshooter
http://WebSupport.sk
*** BERTE A VYCHUTNAVAJTE ***
signature.asc
Description: PGP signature
[Dovecot] Disabling plus sign extension delimiter in lmtp listener (or userdb)
Hello We have migrated our email services from a server, which did not support IMAP and folders, therefore threated the plus sign + as a normal character in a part of an email address. Our new server delivers the emails via lmtp to dovecot. the few users which got a + character in the username first could not log-in (fixed by adding + to auth_username_chars). Now the next problem turn out to be, that the lmtp listener stripps everything after the + sign. The MTA correctly sends the whole email address, so it's not the MTA's fault. It can easily be tested by connecting to the dovecot LMTP listener IP address by telnet: 220 grautvornix.imp.ch Dovecot ready. mail from: 250 2.1.0 OK rcpt to: 550 5.1.1 User doesn't exist: b...@iscan.ch I could not find any configuration parameters for the lmtp listener or userdb service to tell it what to do with the + sign. Did I miss something, or is it impossible to have the + sign accepted as a normal character in an email address? Kind regards -Benoit-
Re: [Dovecot] ot: identifying TB IMAP issues
El 30/05/14 08:28, voy...@sbt.net.au escribió: I have a user with with W7/TBird/IMAP to my dovecot 2.1.17 server, the user complains whilst he is composing lengthy emails (with multiple fowrds/replies quoted in the message) he gets 'hour glass' over compose windows with some message about not being able to save drafts, Has he tried choosing a local folder for drafts?
Re: [Dovecot] Change to Maildir format (Was:Corrupted Mail?)
> -Ursprüngliche Nachricht- > Von: dovecot [mailto:dovecot-boun...@dovecot.org] Im Auftrag von Arthur > Dent > Gesendet: Freitag, 30. Mai 2014 11:25 > An: dovecot@dovecot.org > Betreff: Re: [Dovecot] Change to Maildir format (Was:Corrupted Mail?) > > Well, with thanks to everyone on this list I have now successfully (I > hope) switched from mbox to Maildir format. Moreover I am now using > dovecot-lda to deliver. > > I went step by step, and tested it with just one account before opening up > the whole system. > Great! > I had to rewrite my procmail recipes twice because I first changed them > to: > | /usr/libexec/dovecot/deliver -d mark -m .MLists.Fedora/ > > but after testing with the Maildir format up and running I found that they had > to be: > | /usr/libexec/dovecot/deliver -d mark -m MLists.Fedora > > I will now leave it running for a couple of days. I will keep an eye on the > logs, > but I hope that I have now seen the last of the "Error: Next message > unexpectedly corrupted ..." messages! > Sure! > Thanks again for all the help. Much appreciated! > > Mark
Re: [Dovecot] Change to Maildir format (Was:Corrupted Mail?)
Well, with thanks to everyone on this list I have now successfully (I hope) switched from mbox to Maildir format. Moreover I am now using dovecot-lda to deliver. I went step by step, and tested it with just one account before opening up the whole system. I had to rewrite my procmail recipes twice because I first changed them to: | /usr/libexec/dovecot/deliver -d mark -m .MLists.Fedora/ but after testing with the Maildir format up and running I found that they had to be: | /usr/libexec/dovecot/deliver -d mark -m MLists.Fedora I will now leave it running for a couple of days. I will keep an eye on the logs, but I hope that I have now seen the last of the "Error: Next message unexpectedly corrupted ..." messages! Thanks again for all the help. Much appreciated! Mark
Re: [Dovecot] Filed to write auth token secret file
Just to give it a shot, I took a look into my SELinux log. Problem solved, SELinux blocked it. I added a rule to allow the access and that's it. Thanks for your help Chris On Fri, May 30, 2014 at 2:46 AM, Larry Rosenman wrote: > Can you check all the auth-* process(es) running and make sure they are > all running as root? > > Also, a doveconf -n MIGHT help. > > > On Thu, May 29, 2014 at 1:25 AM, Chris Vaas wrote: > >> So it seems that the permissions are the same like yours. Hm. Suggestions >> about the next step? >> On May 29, 2014 1:12 AM, "Larry Rosenman" wrote: >> >>> the . directory in that list is /var/run/dovecot. >>> >>> that was a ls -la, after a cd /var/run/dovecot. >>> >>> >>> On 5/28/14, Chris Vaas wrote: >>> > May I also ask you for the permissions on the parent folder? >>> > /var/run/dovecot >>> > >>> > Thanks! >>> > >>> > >>> > On Thu, May 29, 2014 at 1:07 AM, Larry Rosenman >>> wrote: >>> > >>> >> Here is the entire contents of mine. >>> >> >>> >> drwxr-xr-x 5 root wheel 35 May 27 21:01 . >>> >> drwxr-xr-x 14 root wheel 35 May 28 03:01 .. >>> >> srw--- 1 root wheel 0 May 24 14:12 anvil >>> >> srw--- 1 root wheel 0 May 24 14:12 anvil-auth-penalty >>> >> srw-rw-rw- 1 dovecot wheel 0 May 27 21:01 auth-client >>> >> srw--- 1 dovecot wheel 0 May 27 21:01 auth-login >>> >> srw-rw-rw- 1 root wheel 0 May 27 21:01 auth-master >>> >> -rw--- 1 root wheel 32 May 24 14:12 >>> auth-token-secret.dat >>> >> srw-rw-rw- 1 dovecot wheel 0 May 27 21:01 auth-userdb >>> >> srw--- 1 dovecot wheel 0 May 27 21:01 auth-worker >>> >> srw--- 1 root wheel 0 May 27 21:01 config >>> >> srw--- 1 root wheel 0 May 27 21:01 dict >>> >> srw--- 1 root wheel 0 May 27 21:01 director-admin >>> >> srw--- 1 root wheel 0 May 27 21:01 director-userdb >>> >> srw-rw-rw- 1 root wheel 0 May 27 21:01 dns-client >>> >> srw--- 1 root wheel 0 May 27 21:01 doveadm-server >>> >> lrwx-- 1 root wheel 35 May 24 14:12 dovecot.conf -> >>> >> /usr/local/etc/dovecot/dovecot.conf >>> >> drwxr-xr-x 2 root wheel 2 May 24 14:12 empty >>> >> srw-rw-rw- 1 root wheel 0 May 27 21:01 imap-urlauth >>> >> srw--- 1 dovecot wheel 0 May 27 21:01 imap-urlauth-worker >>> >> srw-rw-rw- 1 root wheel 0 May 27 21:01 indexer >>> >> srw--- 1 dovecot wheel 0 May 27 21:01 indexer-worker >>> >> srw--- 1 root wheel 0 May 27 21:01 ipc >>> >> srw-rw-rw- 1 root wheel 0 May 27 21:01 lmtp >>> >> srw--- 1 root wheel 0 May 27 21:01 log-errors >>> >> drwxr-x--- 2 root dovenull 9 May 27 21:01 login >>> >> -rw--- 1 root wheel 4 May 24 14:12 master.pid >>> >> -rw-r--r-- 1 root wheel 86 May 24 14:12 mounts >>> >> srw--- 1 root wheel 0 May 27 21:01 replication-notify >>> >> prw--- 1 root wheel 0 May 27 21:01 >>> replication-notify-fifo >>> >> srw--- 1 dovecot wheel 0 May 27 21:01 replicator >>> >> srw-rw-rw- 1 root wheel 0 May 27 21:01 ssl-params >>> >> srw-rw-rw- 1 root wheel 0 May 27 21:01 stats >>> >> prw-rw-rw- 1 root wheel 0 May 27 21:01 stats-mail >>> >> drwxr-x--- 2 root dovenull 4 May 27 21:01 token-login >>> >> thebighonker.lerctr.org /var/run/dovecot $ >>> >> >>> >> >>> >> Now, the fact that it was whining about a .tmp file is interesting. >>> >> >>> >> Was there any other whines? >>> >> >>> >> Seems like something(tm) wasn't running as root that should be. >>> >> >>> >> >>> >> On Wed, May 28, 2014 at 5:52 PM, Chris Vaas >>> wrote: >>> >> >>> >>> What permissions should I have on the folder /var/run/dovecot ? The >>> >>> owner >>> >>> is root and the group dovecot in my case. The access bits are >>> >>> drwxr-xr-x. >>> >>> >>> >>> On Thu, May 29, 2014 at 12:49 AM, Larry Rosenman >> > >>> >>> wrote: >>> >>> >>> >>> > Check the permissions on the directory referenced. >>> >>> > On May 28, 2014 5:06 PM, "Chris Vaas" wrote: >>> >>> > >>> >>> >> Hey guys, >>> >>> >> I am getting the following error. It seems not be be severe, >>> since my >>> >>> >> setup >>> >>> >> works without any signs of drawbacks. But I'd rather rely on a >>> >>> >> professional >>> >>> >> opinion. >>> >>> >> >>> >>> >> May 28 23:02:54 example dovecot: auth: Error: >>> >>> >> open(/var/run/dovecot/auth-token-secret.dat.tmp) failed: >>> Permission >>> >>> denied >>> >>> >> May 28 23:02:54 example dovecot: auth: Error: Failed to write auth >>> >>> token >>> >>> >> secret file; returned tokens will be invalid once auth restarts >>> >>> >> >>> >>> >> Thanks in advance >>> >>> >> Chris >>> >>> >> >>> >>> > >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> Larry Rosenman http://www.lerctr.org/~ler >>> >> Phone: +1 214-642-9640 (c) E-Mail: larry...@gmail.com >>> >> US
