\Noselect isn't set on namespace prefix mailbox that can't be selected
Hi, I tried using Nextcloud's Mail app to access my dovecot server (version: 2.2.27 (c0f36b0)), and got an error. The relevant imap log is: C: 3 LIST () "" (*) RETURN (SPECIAL-USE) ... S: * LIST () "/" Archives ... C: 6 STATUS Archives (MESSAGES) S: 6 NO Mailbox isn't selectable (0.000 + 0.000 secs). >> Command 6 took 0.0014 seconds. C: 7 LOGOUT S: * BYE Logging out S: 7 OK Logout completed (0.000 + 0.000 secs). >> Command 7 took 0.0021 seconds. And the relevant part of my dovecot config: namespace archives { disabled = no hidden = no ignore_on_failure = no inbox = no list = yes location = mbox:~/.mbox-archives order = 0 prefix = Archives/ separator = / subscriptions = yes type = private } Since ~/.mbox-archives is a directory, not a regular file, I'd expect dovecot to set the \Noselect attribute on the Archives folder. Is there something I'm missing? I tried using special_use, but that didn't accept \Noselect as an option.
Re: Dovecot mail_location for fedora
On 19/08/2017 07:17, Joseph Tam wrote: > mail_location=~/.mail:INBOX=/var/spool/mail/%Ln > He should be good now, no idea why a fedora install wouldn't have that Unless I missed something in a previous pst, "~/.mail" is not typical for personal mail folder, but "~/mail" is. Joseph TamI thought that (from earlier example), but not having used mbox in 10 years, couldnt remember, I couldn't example mine because that would throw OP completely (mail_location = maildir:/var/vmail/%Ld/%1Ln/%1.1Ln/%2.1Ln/%Ln/Maildir:INDEX=MEMORY) Since he's not replied, I dare say Aki's post helped him sort it out. -- Kind Regards, Noel Butler This Email, including any attachments, may contain legally privileged information, therefore remains confidential and subject to copyright protected under international law. You may not disseminate, discuss, or reveal, any part, to anyone, without the authors express written authority to do so. If you are not the intended recipient, please notify the sender then delete all copies of this message including attachments, immediately. Confidentiality, copyright, and legal privilege are not waived or lost by reason of the mistaken delivery of this message. Only PDF [1] and ODF [2] documents accepted, please do not send proprietary formatted documents Links: -- [1] http://www.adobe.com/ [2] http://en.wikipedia.org/wiki/OpenDocument
Permission denied to access the email file
Hi, Dovecot version : 2.2.22 (fe789d2) Operating system : DISTRIB_ID=Ubuntu DISTRIB_RELEASE=16.04 DISTRIB_CODENAME=xenial DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS" CPU architecture : Linux 4.4.67-1-pve #1 SMP PVE 4.4.67-92 (Fri, 23 Jun 2017 08:22:06 +0200) x86_64 GNU/Linux FIle system : local UIDGID Aug 17 11:47:28 azizee dovecot: imap(jra11[*5063*:*5011*]): Debug: Effective uid=5063, gid=5011, home=/var/spool/domaines/vitalnet/jra/ Aug 17 11:47:28 azizee dovecot: imap(jra11[5063:5011]): Debug: Namespace inbox: type=private, prefix=, sep=, inbox=yes, hidden=no, list=yes, subscriptions=yes location=maildir:/var/spool/domaines/vitalnet/jra/ Aug 17 11:47:28 azizee dovecot: imap(jra11[5063:5011]): Debug: maildir++: root=/var/spool/domaines/vitalnet/jra, index=, indexpvt=, control=, inbox=/var/spool/domaines/vitalnet/jra, alt= Aug 17 11:47:28 azizee dovecot: imap(jra11[5063:5011]): *Error*: open(/var/spool/domaines/vitalnet/jra/cur/1502890181.V704I34050fM371072.azizee:2,) failed: *Permission denied* (euid=*5063*() egid=*5011*() missing +r perm: /var/spool/domaines/vitalnet/jra/cur/1502890181.V704I34050fM371072.azizee:2,) Ldap configuration : user_attrs = uid=user,userPassword=password,homeDirectory=home,uidNumber=uid,gidNumber=gid ll /var/spool/domaines/vitalnet/jra/cur/1502890181.V704I34050fM371072.azizee\:2\, -rw--- 1 5095 5011 438 Aug 16 15:29 /var/spool/domaines/vitalnet/jra/cur/1502890181.V704I34050fM371072.azizee:2, If I set with the command line "chmod g=rw /var/spool/domaines/vitalnet/jra/cur/1502890181.V704I34050fM371072.azizee\:2\,", this file email is treated by Dovecot, per example, i have deleted it. ll /var/spool/domaines/vitalnet/jra/cur/1502890181.V704I34050fM371072.azizee\:2\,ST -rw-rw 1 5095 5011 438 Aug 16 15:29 /var/spool/domaines/vitalnet/jra/cur/1502890181.V704I34050fM371072.azizee:2,ST What's the problem of my configuration ? Best regards,
Re: Dovecot mail_location for fedora
mail_location=~/.mail:INBOX=/var/spool/mail/%Ln He should be good now, no idea why a fedora install wouldn't have that Unless I missed something in a previous pst, "~/.mail" is not typical for personal mail folder, but "~/mail" is. Joseph Tam
Re: Inconsistency in map index
On Fri, Aug 18, 2017 at 1:30 PM, Timo Sirainenwrote: > > That would work. Also as a different workaround you could just rm > storage/dovecot.map.index* and doveadm force-resync -u user@domain '*'. Thank you Timo, that did the trick without the need of a sudden upgrade. Mailbox was fixed :) Regards, Webert Lima DevOps Engineer at MAV Tecnologia *Belo Horizonte - Brasil* > >
Re: Inconsistency in map index
On 18 Aug 2017, at 16.43, Webert de Souza Limawrote: > > On Fri, Aug 18, 2017 at 9:03 AM, Aki Tuomi wrote: > >> This is fixed in next release (2.2.32) with >> https://github.com/dovecot/core/commit/c8be394 >> >> Aki Tuomi >> > > As this is still a release candidate, I'm thinking of running an isolated > instance of this version, and do doveadm force-resync just to fix just this > user's mailbox. > What do you think? That would work. Also as a different workaround you could just rm storage/dovecot.map.index* and doveadm force-resync -u user@domain '*'. Should be also safe to do (won't lose any information), although I guess it has some potential of race conditions causing temporary problems if the user accesses mails at the same time.
Re: Install locks up my server
No idea. config.guess is generated by autotools, so I don't think I can really affect it anyway. Also it works fine at least in CentOS 6.7 & 6.9. My guess is also that it might work ok in CentOS 6.6 and the brokenness is somehow specific to your system. > On 18 Aug 2017, at 18.43, Marc Perkelwrote: > > This is still broken in the 2.2.32 release candidate. config.guess forks > copies till the server dies. Running Centos 6.6 under OpenVZ. > > On 06/26/17 16:03, Marc Perkel wrote: >> >> >> On 06/26/17 14:42, Timo Sirainen wrote: >>> On 26 Jun 2017, at 23.19, Marc Perkel wrote: Ever since 2.26 I haven't been able to upgrade. In fact the install locks up my server. I get into and infinite recursive loop where the config-guess program calls itself until the server locks up from overload. I'm running Centos 6 under OpenVZ. What am I missing? I think there's a serious bug. 31233 pts/3S 0:00 /bin/sh ./config.guess 31235 pts/3S 0:00 \_ /bin/sh ./config.guess 31238 pts/3S 0:00 \_ /bin/sh ./config.guess 31240 pts/3S 0:00 \_ /bin/sh ./config.guess >>> I think I remember seeing this before, but unfortunately can't remember >>> what the solution was. Maybe it was something something messed up in the OS >>> or in the build directory. Are you compiling from the tarballs? So it's the >>> "configure" that fails? Also if you run "./config.guess" manually? What's >>> the output if you run "bash -x ./config.guess"? >>> >>> >>> >> >> bash -x ./config.guess >> + timestamp=2015-08-20 >> ++ sed -e 's,.*/,,' >> ++ echo ./config.guess >> + me=config.guess >> + usage='Usage: ./config.guess [OPTION] >> >> Output the configuration name of the system `config.guess'\'' is run on. >> >> Operation modes: >> -h, --help print this help, then exit >> -t, --time-stamp print date of last modification, then exit >> -v, --version print version number, then exit >> >> Report bugs and patches to .' >> + version='GNU config.guess (2015-08-20) >> >> Originally written by Per Bothner. >> Copyright 1992-2015 Free Software Foundation, Inc. >> >> This is free software; see the source for copying conditions. There is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.' >> + help=' >> Try `config.guess --help'\'' for more information.' >> + test 0 -gt 0 >> + test 0 '!=' 0 >> + trap 'exit 1' 1 2 15 >> + set_cc_for_build=' >> trap "exitcode=\$?; (rm -f \$tmpfiles 2>/dev/null; rmdir \$tmp 2>/dev/null) >> && exit \$exitcode" 0 ; >> trap "rm -f \$tmpfiles 2>/dev/null; rmdir \$tmp 2>/dev/null; exit 1" 1 2 13 >> 15 ; >> : ${TMPDIR=/tmp} ; >> { tmp=`(umask 077 && mktemp -d "$TMPDIR/cgXX") 2>/dev/null` && test -n >> "$tmp" && test -d "$tmp" ; } || >> { test -n "$RANDOM" && tmp=$TMPDIR/cg$$-$RANDOM && (umask 077 && mkdir $tmp) >> ; } || >> { tmp=$TMPDIR/cg-$$ && (umask 077 && mkdir $tmp) && echo "Warning: creating >> insecure temp directory" >&2 ; } || >> { echo "$me: cannot create a temporary directory in $TMPDIR" >&2 ; exit 1 ; >> } ; >> dummy=$tmp/dummy ; >> tmpfiles="$dummy.c $dummy.o $dummy.rel $dummy" ; >> case $CC_FOR_BUILD,$HOST_CC,$CC in >> ,,)echo "int x;" > $dummy.c ; >>for c in cc gcc c89 c99 ; do >> if ($c -c -o $dummy.o $dummy.c) >/dev/null 2>&1 ; then >> CC_FOR_BUILD="$c"; break ; >> fi ; >>done ; >>if test x"$CC_FOR_BUILD" = x ; then >> CC_FOR_BUILD=no_compiler_found ; >>fi >>;; >> ,,*) CC_FOR_BUILD=$CC ;; >> ,*,*) CC_FOR_BUILD=$HOST_CC ;; >> esac ; set_cc_for_build= ;' >> + UNAME_MACHINE=x86_64 >> + UNAME_RELEASE=2.6.32-042stab123.3 >> + UNAME_SYSTEM=Linux >> + UNAME_VERSION='#1 SMP Fri May 5 12:29:05 MSK 2017' >> + case "${UNAME_SYSTEM}" in >> + LIBC=gnu >> + eval trap '"exitcode=\$?;' '(rm' -f '\$tmpfiles' '2>/dev/null;' rmdir >> '\$tmp' '2>/dev/null)' '&&' exit '\$exitcode"' 0 ';' trap '"rm' -f >> '\$tmpfiles' '2>/dev/null;' rmdir '\$tmp' '2>/dev/null;' exit '1"' 1 2 13 15 >> ';' : '${TMPDIR=/tmp}' ';' '{' 'tmp=`(umask' 077 '&&' mktemp -d >> '"$TMPDIR/cgXX")' '2>/dev/null`' '&&' test -n '"$tmp"' '&&' test -d >> '"$tmp"' ';' '}' '||' '{' test -n '"$RANDOM"' '&&' >> 'tmp=$TMPDIR/cg$$-$RANDOM' '&&' '(umask' 077 '&&' mkdir '$tmp)' ';' '}' '||' >> '{' 'tmp=$TMPDIR/cg-$$' '&&' '(umask' 077 '&&' mkdir '$tmp)' '&&' echo >> '"Warning:' creating insecure temp 'directory"' '>&2' ';' '}' '||' '{' echo >> '"$me:' cannot create a temporary directory in '$TMPDIR"' '>&2' ';' exit 1 >> ';' '}' ';' 'dummy=$tmp/dummy' ';' 'tmpfiles="$dummy.c' '$dummy.o' >> '$dummy.rel' '$dummy"' ';' case '$CC_FOR_BUILD,$HOST_CC,$CC' in ',,)' echo >> '"int' 'x;"' '>' '$dummy.c' ';' for c in cc gcc c89 c99 ';' do if '($c' -c >> -o '$dummy.o' '$dummy.c)' '>/dev/null' '2>&1' ';' then 'CC_FOR_BUILD="$c";' >> break ';' fi ';' done ';' if test
Re: Install locks up my server
This is still broken in the 2.2.32 release candidate. config.guess forks copies till the server dies. Running Centos 6.6 under OpenVZ. On 06/26/17 16:03, Marc Perkel wrote: On 06/26/17 14:42, Timo Sirainen wrote: On 26 Jun 2017, at 23.19, Marc Perkelwrote: Ever since 2.26 I haven't been able to upgrade. In fact the install locks up my server. I get into and infinite recursive loop where the config-guess program calls itself until the server locks up from overload. I'm running Centos 6 under OpenVZ. What am I missing? I think there's a serious bug. 31233 pts/3S 0:00 /bin/sh ./config.guess 31235 pts/3S 0:00 \_ /bin/sh ./config.guess 31238 pts/3S 0:00 \_ /bin/sh ./config.guess 31240 pts/3S 0:00 \_ /bin/sh ./config.guess I think I remember seeing this before, but unfortunately can't remember what the solution was. Maybe it was something something messed up in the OS or in the build directory. Are you compiling from the tarballs? So it's the "configure" that fails? Also if you run "./config.guess" manually? What's the output if you run "bash -x ./config.guess"? bash -x ./config.guess + timestamp=2015-08-20 ++ sed -e 's,.*/,,' ++ echo ./config.guess + me=config.guess + usage='Usage: ./config.guess [OPTION] Output the configuration name of the system `config.guess'\'' is run on. Operation modes: -h, --help print this help, then exit -t, --time-stamp print date of last modification, then exit -v, --version print version number, then exit Report bugs and patches to .' + version='GNU config.guess (2015-08-20) Originally written by Per Bothner. Copyright 1992-2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.' + help=' Try `config.guess --help'\'' for more information.' + test 0 -gt 0 + test 0 '!=' 0 + trap 'exit 1' 1 2 15 + set_cc_for_build=' trap "exitcode=\$?; (rm -f \$tmpfiles 2>/dev/null; rmdir \$tmp 2>/dev/null) && exit \$exitcode" 0 ; trap "rm -f \$tmpfiles 2>/dev/null; rmdir \$tmp 2>/dev/null; exit 1" 1 2 13 15 ; : ${TMPDIR=/tmp} ; { tmp=`(umask 077 && mktemp -d "$TMPDIR/cgXX") 2>/dev/null` && test -n "$tmp" && test -d "$tmp" ; } || { test -n "$RANDOM" && tmp=$TMPDIR/cg$$-$RANDOM && (umask 077 && mkdir $tmp) ; } || { tmp=$TMPDIR/cg-$$ && (umask 077 && mkdir $tmp) && echo "Warning: creating insecure temp directory" >&2 ; } || { echo "$me: cannot create a temporary directory in $TMPDIR" >&2 ; exit 1 ; } ; dummy=$tmp/dummy ; tmpfiles="$dummy.c $dummy.o $dummy.rel $dummy" ; case $CC_FOR_BUILD,$HOST_CC,$CC in ,,)echo "int x;" > $dummy.c ; for c in cc gcc c89 c99 ; do if ($c -c -o $dummy.o $dummy.c) >/dev/null 2>&1 ; then CC_FOR_BUILD="$c"; break ; fi ; done ; if test x"$CC_FOR_BUILD" = x ; then CC_FOR_BUILD=no_compiler_found ; fi ;; ,,*) CC_FOR_BUILD=$CC ;; ,*,*) CC_FOR_BUILD=$HOST_CC ;; esac ; set_cc_for_build= ;' + UNAME_MACHINE=x86_64 + UNAME_RELEASE=2.6.32-042stab123.3 + UNAME_SYSTEM=Linux + UNAME_VERSION='#1 SMP Fri May 5 12:29:05 MSK 2017' + case "${UNAME_SYSTEM}" in + LIBC=gnu + eval trap '"exitcode=\$?;' '(rm' -f '\$tmpfiles' '2>/dev/null;' rmdir '\$tmp' '2>/dev/null)' '&&' exit '\$exitcode"' 0 ';' trap '"rm' -f '\$tmpfiles' '2>/dev/null;' rmdir '\$tmp' '2>/dev/null;' exit '1"' 1 2 13 15 ';' : '${TMPDIR=/tmp}' ';' '{' 'tmp=`(umask' 077 '&&' mktemp -d '"$TMPDIR/cgXX")' '2>/dev/null`' '&&' test -n '"$tmp"' '&&' test -d '"$tmp"' ';' '}' '||' '{' test -n '"$RANDOM"' '&&' 'tmp=$TMPDIR/cg$$-$RANDOM' '&&' '(umask' 077 '&&' mkdir '$tmp)' ';' '}' '||' '{' 'tmp=$TMPDIR/cg-$$' '&&' '(umask' 077 '&&' mkdir '$tmp)' '&&' echo '"Warning:' creating insecure temp 'directory"' '>&2' ';' '}' '||' '{' echo '"$me:' cannot create a temporary directory in '$TMPDIR"' '>&2' ';' exit 1 ';' '}' ';' 'dummy=$tmp/dummy' ';' 'tmpfiles="$dummy.c' '$dummy.o' '$dummy.rel' '$dummy"' ';' case '$CC_FOR_BUILD,$HOST_CC,$CC' in ',,)' echo '"int' 'x;"' '>' '$dummy.c' ';' for c in cc gcc c89 c99 ';' do if '($c' -c -o '$dummy.o' '$dummy.c)' '>/dev/null' '2>&1' ';' then 'CC_FOR_BUILD="$c";' break ';' fi ';' done ';' if test 'x"$CC_FOR_BUILD"' = x ';' then CC_FOR_BUILD=no_compiler_found ';' fi ';;' ',,*)' 'CC_FOR_BUILD=$CC' ';;' ',*,*)' 'CC_FOR_BUILD=$HOST_CC' ';;' esac ';' set_cc_for_build= ';' ++ trap 'exitcode=$?; (rm -f $tmpfiles 2>/dev/null; rmdir $tmp 2>/dev/null) && exit $exitcode' 0 ++ trap 'rm -f $tmpfiles 2>/dev/null; rmdir $tmp 2>/dev/null; exit 1' 1 2 13 15 ++ : /tmp ++ tmp=/tmp/cgpmW24a ++ test -n /tmp/cgpmW24a ++ test -d /tmp/cgpmW24a ++ dummy=/tmp/cgpmW24a/dummy ++ tmpfiles='/tmp/cgpmW24a/dummy.c /tmp/cgpmW24a/dummy.o /tmp/cgpmW24a/dummy.rel /tmp/cgpmW24a/dummy' ++ case $CC_FOR_BUILD,$HOST_CC,$CC in ++ echo 'int x;' ++ for c in cc gcc c89 c99
Re: Inconsistency in map index
On Fri, Aug 18, 2017 at 9:03 AM, Aki Tuomiwrote: > This is fixed in next release (2.2.32) with > https://github.com/dovecot/core/commit/c8be394 > > Aki Tuomi > As this is still a release candidate, I'm thinking of running an isolated instance of this version, and do doveadm force-resync just to fix just this user's mailbox. What do you think? Regards, Webert Lima DevOps Engineer at MAV Tecnologia *Belo Horizonte - Brasil*
Re: Inconsistency in map index
Oh, so that's likely a bug. I was thinking it would require manual intervention to fix. Great, I'll do an upgrade ASAP. Praised be Docker. Thank you very much. Regards, Webert Lima DevOps Engineer at MAV Tecnologia *Belo Horizonte - Brasil* On Fri, Aug 18, 2017 at 9:03 AM, Aki Tuomiwrote: > > > On 18.08.2017 14:55, Webert de Souza Lima wrote: > > Hello, > > > > The following errors are constantly popping up for 2 accounts. I can't > get > > it fixed, > > I did doveadm backup to another account, the same happens in the new > > account. > > I did doveadm force-resync, the problem persists. > > > > I'm using dovecot 2.2. > > > > 2017-08-18T11:46:12.472821881Z Aug 18 11:46:12 lmtp( > ramon.lace...@alliar.com): > > Warning: mdbox /srv/dovecot2/mail/alliar.com/ramon.lacerda/storage: > > Inconsistency in map index (647,6288 != 647,28333584) > > > > 2017-08-18T11:46:12.651002372Z Aug 18 11:46:12 lmtp( > ramon.lace...@alliar.com): > > Warning: mdbox /srv/dovecot2/mail/alliar.com/ramon.lacerda/storage: > > Inconsistency in map index (647,6288 != 647,28333708) > > > > 2017-08-18T11:46:12.651059432Z Aug 18 11:46:12 lmtp( > ramon.lace...@alliar.com): > > Warning: fscking index file /srv/dovecot2/index/ > > alliar.com/ramon.lacerda/storage/dovecot.map.index > > > > 2017-08-18T11:46:12.764926940Z Aug 18 11:46:12 lmtp( > ramon.lace...@alliar.com): > > Warning: mdbox /srv/dovecot2/mail/alliar.com/ramon.lacerda/storage: > > rebuilding indexes > > > > > > Regards, > > > > Webert Lima > > DevOps Engineer at MAV Tecnologia > > *Belo Horizonte - Brasil* > > Hi! > > This is fixed in next release (2.2.32) with > https://github.com/dovecot/core/commit/c8be394 > > Aki Tuomi >
Re: /var/run/dovecot permission issues
I'm glad to read this thread. I didn't even know that dovecot stats existed. Which statistics do you find most useful? Bill On 8/17/2017 3:31 PM, Matt Simpson wrote: On Aug 17, 2017, at 12:07 PM, Larry Rosenmanwrote: In /usr/local/etc/dovecot/conf.d/90-plugin.conf: Thanks. Those config statements fixed the problem.
Filter of old Thunderbird installation interferes with lmtp/ Mail delivery / sieve
# 2.2.13: /etc/dovecot/dovecot.conf # OS: Linux 4.9.25 i686 Gentoo Base System release 2.2 # pidgeonhole v0.4.3 # Thunderbird 3.0.4 impact -- Emails, for which the filter applies, gets copied to the desired folder, but get kept in the inbox with deleted flag (in Roundcube you see them grayed out a bit, in Thunderbird they are not shown at all). When the incoming email is from an internal mailing list (mailman), beginning with the user with the buggy Thunderbird all following emails of the internal users are flagged as deleted, but only if the user has a sieve file in their directory - no matter whether it is active or not. After activating detailed logging the user with the "problematic" filter was found quickly. The error is reproducible: - install old Thunderbird version - create filter - write an email, which triggers the filter -> email is flagged deleted but does not get deleted Though, the user does not have a sieve file on our server, the filtering happened in the very same second when the email was delivered to the other colleagues. Both Thunderbird and Pidgeonhole are outdated, so I am unsure if you are even interested in this bug report. Fix --- I made the user to update his Thunderbird version -> no more problems. Anyhow, a single "user interaction" should not be able to effect other mail accounts (ie Thunderbirds filter somehow disturbed the lmtp process). -- Jürgen Gmach . juergen.gm...@apis.de . +49 9482 941545 APIS Informationstechnologien GmbH . http://www.apis.de Gewerbepark A 13, 93086 Wörth/Donau . Deutschland Sitz der GmbH: Wörth/Donau, Amtsgericht Regensburg (HRB 6684) Geschäftsführer: Julia Anna Dietz, Jürgen Eilers, Peter Rosenbeck
Re: Inconsistency in map index
On 18.08.2017 14:55, Webert de Souza Lima wrote: > Hello, > > The following errors are constantly popping up for 2 accounts. I can't get > it fixed, > I did doveadm backup to another account, the same happens in the new > account. > I did doveadm force-resync, the problem persists. > > I'm using dovecot 2.2. > > 2017-08-18T11:46:12.472821881Z Aug 18 11:46:12 lmtp(ramon.lace...@alliar.com): > Warning: mdbox /srv/dovecot2/mail/alliar.com/ramon.lacerda/storage: > Inconsistency in map index (647,6288 != 647,28333584) > > 2017-08-18T11:46:12.651002372Z Aug 18 11:46:12 lmtp(ramon.lace...@alliar.com): > Warning: mdbox /srv/dovecot2/mail/alliar.com/ramon.lacerda/storage: > Inconsistency in map index (647,6288 != 647,28333708) > > 2017-08-18T11:46:12.651059432Z Aug 18 11:46:12 lmtp(ramon.lace...@alliar.com): > Warning: fscking index file /srv/dovecot2/index/ > alliar.com/ramon.lacerda/storage/dovecot.map.index > > 2017-08-18T11:46:12.764926940Z Aug 18 11:46:12 lmtp(ramon.lace...@alliar.com): > Warning: mdbox /srv/dovecot2/mail/alliar.com/ramon.lacerda/storage: > rebuilding indexes > > > Regards, > > Webert Lima > DevOps Engineer at MAV Tecnologia > *Belo Horizonte - Brasil* Hi! This is fixed in next release (2.2.32) with https://github.com/dovecot/core/commit/c8be394 Aki Tuomi
Inconsistency in map index
Hello, The following errors are constantly popping up for 2 accounts. I can't get it fixed, I did doveadm backup to another account, the same happens in the new account. I did doveadm force-resync, the problem persists. I'm using dovecot 2.2. 2017-08-18T11:46:12.472821881Z Aug 18 11:46:12 lmtp(ramon.lace...@alliar.com): Warning: mdbox /srv/dovecot2/mail/alliar.com/ramon.lacerda/storage: Inconsistency in map index (647,6288 != 647,28333584) 2017-08-18T11:46:12.651002372Z Aug 18 11:46:12 lmtp(ramon.lace...@alliar.com): Warning: mdbox /srv/dovecot2/mail/alliar.com/ramon.lacerda/storage: Inconsistency in map index (647,6288 != 647,28333708) 2017-08-18T11:46:12.651059432Z Aug 18 11:46:12 lmtp(ramon.lace...@alliar.com): Warning: fscking index file /srv/dovecot2/index/ alliar.com/ramon.lacerda/storage/dovecot.map.index 2017-08-18T11:46:12.764926940Z Aug 18 11:46:12 lmtp(ramon.lace...@alliar.com): Warning: mdbox /srv/dovecot2/mail/alliar.com/ramon.lacerda/storage: rebuilding indexes Regards, Webert Lima DevOps Engineer at MAV Tecnologia *Belo Horizonte - Brasil*
Re: dotlock causing crashes
On 16.08.2017 21:17, Ian Bobbitt wrote: > OS: CentOS 7 x86_64 > Dovecot version: 2.2.31 (65cde28) (GhettoForge RPM) > Filesystem: GlusterFS, but working on changing that. Only one server is > receiving activity. > > Was getting messages about corrupt dovecot.map.index files. Changed to > dotlock from fcntl to try to fix that. > > Reading symbols from /usr/libexec/dovecot/imap...(no debugging symbols > found)...done. > [New LWP 74012] > Core was generated by `dovecot/imap'. > Program terminated with signal 6, Aborted. > #0 0x7fa262c741d7 in __GI_raise (sig=sig@entry=6) at > ../nptl/sysdeps/unix/sysv/linux/raise.c:56 > 56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); > (gdb) bt full > #0 0x7fa262c741d7 in __GI_raise (sig=sig@entry=6) at > ../nptl/sysdeps/unix/sysv/linux/raise.c:56 > resultvar = 0 > pid = 74012 > selftid = 74012 > #1 0x7fa262c758c8 in __GI_abort () at abort.c:90 > save_stage = 2 > act = {__sigaction_handler = {sa_handler = 0x7ffd7009f401, > sa_sigaction = 0x7ffd7009f401}, sa_mask = {__val = > {0, 0, 140335431377968, 140335423109592, 140335422613219, 4246482, > 140335418575669, 12278048, 4192326493288016896, > 12278592, 140335423192931, 0, 0, 140335425698848, 12280232, > 140726483153732}}, sa_flags = 1657305400, sa_restorer = 0x79a} > sigs = {__val = {32, 0 }} > #2 0x7fa26309eac6 in default_fatal_finish (type=, > status=status@entry=0) at failures.c:201 > backtrace = 0xbb5958 "/usr/lib64/dovecot/libdovecot.so.0(+0x9eace) > [0x7fa26309eace] -> > /usr/lib64/dovecot/libdovecot.so.0(+0x9ebae) [0x7fa26309ebae] -> > /usr/lib64/dovecot/libdovecot.so.0(i_fatal+0) > [0x7fa26303012c] -> /usr"... > #3 0x7fa26309ebae in i_internal_fatal_handler (ctx=0x7ffd7009f4d0, > format=, args=) at > failures.c:670 > status = 0 > #4 0x7fa26303012c in i_panic (format=format@entry=0x7fa2630d11de "file > %s: line %d: unreached") at failures.c:275 > ctx = {type = LOG_TYPE_PANIC, exit_status = 0, timestamp = 0x0, > timestamp_usecs = 0} > args = {{gp_offset = 24, fp_offset = 48, overflow_arg_area = > 0x7ffd7009f5d0, reg_save_area = 0x7ffd7009f510}} > #5 0x7fa2630a344f in file_lock_do (fd=fd@entry=20, > path=path@entry=0xbb5868 > "/gnoc/mail/home/bgeels/mail/mailboxes/Junk/dbox-Mails/.vsize.lock23f657caa43d8796", > lock_type=lock_type@entry=1, > lock_method=lock_method@entry=FILE_LOCK_METHOD_DOTLOCK, timeout_secs=0, > error_r=error_r@entry=0x7ffd7009f768) at > file-lock.c:285 > lock_type_str = 0x7fa2630e6948 "write-lock" > started = 1502905468 > ret = > __FUNCTION__ = "file_lock_do" > #6 0x7fa2630a3796 in file_wait_lock_error (fd=20, path=0xbb5868 > "/gnoc/mail/home/bgeels/mail/mailboxes/Junk/dbox-Mails/.vsize.lock23f657caa43d8796", > lock_type=1, > lock_method=FILE_LOCK_METHOD_DOTLOCK, timeout_secs=, > lock_r=0xc4ec10, error_r=0x7ffd7009f768) at > file-lock.c:314 > ret = > #7 0x7fa2630a3813 in file_try_lock_error (fd=, > path=, lock_type=lock_type@entry=1, > lock_method=lock_method@entry=FILE_LOCK_METHOD_DOTLOCK, > lock_r=lock_r@entry=0xc4ec10, > error_r=error_r@entry=0x7ffd7009f768) at file-lock.c:66 > No locals. > #8 0x7fa2630a0955 in try_create_new (error_r=0x7ffd7009f768, > lock_r=0xc4ec10, fd_r=0x7ffd7009f700, > set=0x7ffd7009f770, path=0xc2f930 > "/gnoc/mail/home/bgeels/mail/mailboxes/Junk/dbox-Mails/.vsize.lock") at > file-create-locked.c:65 > fd = 20 > orig_errno = > ret = -1 > temp_path = 0xbb5830 > mode = 0 > uid = > gid = 4294967295 > #9 file_create_locked (path=0xc2f930 > "/gnoc/mail/home/bgeels/mail/mailboxes/Junk/dbox-Mails/.vsize.lock", > set=set@entry=0x7ffd7009f770, lock_r=lock_r@entry=0xc4ec10, > created_r=created_r@entry=0x7ffd7009f767, > error_r=error_r@entry=0x7ffd7009f768) at file-create-locked.c:118 > i = 0 > fd = > ret = > __FUNCTION__ = "file_create_locked" > #10 0x7fa2633e8f80 in vsize_update_lock_full (update=0xc4ebd0, > lock_secs=lock_secs@entry=0) at index-mailbox-size.c:150 > box = 0xc2e268 > perm = 0xc2e440 > set = {lock_timeout_secs = 0, lock_method = FILE_LOCK_METHOD_DOTLOCK, > mode = 384, uid = 0, gid = 4294967295, > gid_origin = 0xc2ea58 "/gnoc/mail/home/bgeels/mail/mailboxes/Junk"} > error = 0x7fa2633f2062> "1\300[]A\\\303\017\037\200" > created = false > #11 0x7fa2633e9057 in index_mailbox_vsize_update_try_lock > (update=) at index-mailbox-size.c:167 > No locals. > #12 0x7fa2633e9755 in index_mailbox_vsize_update_appends (box= out>) at index-mailbox-size.c:479 > update = 0xc4ebd0 > status = {messages = 1323, recent = 0, unseen = 0, uidvalidity = > 1413091786, uidnext = 6750, first_unseen_seq = > 0, first_recent_uid = 5886, last_cached_seq = 0, highest_modseq = 0, > highest_pvt_modseq
Re: is a self signed certificate always invalid the first time?
On 18.08.2017 09:12, voy...@sbt.net.au wrote: > for a public web server where https is becoming mandatory, I'd still > need a certificate from a recognized publisher, to avoid users geting > 'warnings', is that so ? For a certificate to be reported as "valid", an unbroken chain of cryptographic signatures is required. Browsers are released with a set of Root CA and Intermediate CA certificates, as are operating systems. Some use the Mozilla CA Certificate Store[1], for example, others come with their own CA stores, like macOS[2]. [1] https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/ [2] https://support.apple.com/en-us/HT202858 Unless your web server certificate's signature chain originates from one of the CAs delivered with a web browser or OS, the end user connecting to your site will either have to manually add the required CAs, or add your server certificate, or be presented with a warning/error message. One could argue that relying on certificate stores is placing personal security concerns in other people's hands. Of course, it would be a potentially funny thing to try and verify the validity of your online banking server's certificate by asking them to send you a letter containing the certificate fingerprint... -Ralph
Re: is a self signed certificate always invalid the first time?
On 18.08.2017 08:58, Michael Felt wrote: > as Ralph mentions in his reply - Let's encrypt certs are only for > three months - never ending circus. I don't consider the 90-day-lifespan a "circus". It is meant as a security feature[1], and Let's Encrypt suggests using automation for certificate renewal. Also, with ACME v2 on the horizon[2], I imagine that more automation tools will become available. [1] https://letsencrypt.org/2015/11/09/why-90-days.html [2] https://letsencrypt.org/2017/06/14/acme-v2-api.html Let's not forget that Let's Encrypt is still a young service, and that it is free. -Ralph
Re: Dovecot mail_location for fedora
Ahh thats it :) He should be good now, no idea why a fedora install wouldn't have that On 18/08/2017 19:43, Aki Tuomi wrote: > mail_location=~/.mail:INBOX=/var/spool/mail/%Ln > > Aki -- Kind Regards, Noel Butler This Email, including any attachments, may contain legally privileged information, therefore remains confidential and subject to copyright protected under international law. You may not disseminate, discuss, or reveal, any part, to anyone, without the authors express written authority to do so. If you are not the intended recipient, please notify the sender then delete all copies of this message including attachments, immediately. Confidentiality, copyright, and legal privilege are not waived or lost by reason of the mistaken delivery of this message. Only PDF [1] and ODF [2] documents accepted, please do not send proprietary formatted documents Links: -- [1] http://www.adobe.com/ [2] http://en.wikipedia.org/wiki/OpenDocument signature.asc Description: OpenPGP digital signature
Re: Dovecot mail_location for fedora
mail_location=~/.mail:INBOX=/var/spool/mail/%Ln Aki On 18.08.2017 12:41, Noel Butler wrote: > On 18/08/2017 06:15, Randy Gordey wrote: > >> What is the syntax for dovecot mail_location when postfix delivers mail to >> /var/spool/mail/? >> >> These are the old unix style mbox, one file per user. >> >> Not setting mail_location in 10-mail.conf results in Auto not finding it. >> >> mbox: /var/spool/mail/%u said mbox root directory can't be a file. > Its been over 10 years since I've run mbox, but i'm sure your format is > wrong, you're also not supposed to use spaces either, in fact I think > its telling you whats wrong, from memory, its mbox:~/mail: > but I cant recall what otherstuff is I know the pathis in it but it > needs something before it, I just cant recall what, see the wiki, I'd be > highly surprised if it did not explain it. > >> mbox: /var/spool/mail/ tries to make Sent and Deleted Folders, etc. >> >> maildir: /var/spool/mail/ closes the connection. > Thats not how maildir works you need to add the Maildir directory to it, > ie maildir:/var/spool/mail/%n/Maildir > > but DO NOT USE THAT directory! And its more than dovecot you need to > change if you're going to use maildir, so just fix up your mbox > settings. >
Re: Dovecot mail_location for fedora
On 18/08/2017 06:15, Randy Gordey wrote: > What is the syntax for dovecot mail_location when postfix delivers mail to > /var/spool/mail/? > > These are the old unix style mbox, one file per user. > > Not setting mail_location in 10-mail.conf results in Auto not finding it. > > mbox: /var/spool/mail/%u said mbox root directory can't be a file. Its been over 10 years since I've run mbox, but i'm sure your format is wrong, you're also not supposed to use spaces either, in fact I think its telling you whats wrong, from memory, its mbox:~/mail: but I cant recall what otherstuff is I know the pathis in it but it needs something before it, I just cant recall what, see the wiki, I'd be highly surprised if it did not explain it. > mbox: /var/spool/mail/ tries to make Sent and Deleted Folders, etc. > > maildir: /var/spool/mail/ closes the connection. Thats not how maildir works you need to add the Maildir directory to it, ie maildir:/var/spool/mail/%n/Maildir but DO NOT USE THAT directory! And its more than dovecot you need to change if you're going to use maildir, so just fix up your mbox settings. -- Kind Regards, Noel Butler This Email, including any attachments, may contain legally privileged information, therefore remains confidential and subject to copyright protected under international law. You may not disseminate, discuss, or reveal, any part, to anyone, without the authors express written authority to do so. If you are not the intended recipient, please notify the sender then delete all copies of this message including attachments, immediately. Confidentiality, copyright, and legal privilege are not waived or lost by reason of the mistaken delivery of this message. Only PDF [1] and ODF [2] documents accepted, please do not send proprietary formatted documents Links: -- [1] http://www.adobe.com/ [2] http://en.wikipedia.org/wiki/OpenDocument signature.asc Description: OpenPGP digital signature
Re: is a self signed certificate always invalid the first time?
On 18/08/2017 17:12, voy...@sbt.net.au wrote: > BUT, for a public web server where https is becoming mandatory, I'd still > need a certificate from a recognized publisher, to avoid users geting > 'warnings', is that so ? > > (I'm currently using self issued for both mail and web) > > thanks, > > V It depends on what you're uses are, self signed certs are OK for smtp/pop3/imap, since most people are just concerned with "encryption" in that case, but a different story if its web content, in particular, shopping carts and the like, If you have clients content, definitely use a real cert, maybe in 10 years letsencrypt might make the grade, but until every bit of software and OS supports it and they offer insurance levels like the bi boys do, you might as well be using a self signed cert, comodo are pretty cheap with basic insurance level on even the most basic of their offerings. Do your research, though if using a paid service, since some others are soon to be un-trusted. -- Kind Regards, Noel Butler This Email, including any attachments, may contain legally privileged information, therefore remains confidential and subject to copyright protected under international law. You may not disseminate, discuss, or reveal, any part, to anyone, without the authors express written authority to do so. If you are not the intended recipient, please notify the sender then delete all copies of this message including attachments, immediately. Confidentiality, copyright, and legal privilege are not waived or lost by reason of the mistaken delivery of this message. Only PDF [1] and ODF [2] documents accepted, please do not send proprietary formatted documents Links: -- [1] http://www.adobe.com/ [2] http://en.wikipedia.org/wiki/OpenDocument signature.asc Description: OpenPGP digital signature
Re: is a self signed certificate always invalid the first time
Obviously you do not use clustered environments with more than one node per service. Else you would not call it "it just works", because in fact the renewal is quite big bs as one node must do the job while all the others must be _offline_. I'm not sure how you have set up your clustered service, but why do your nodes have to go offline? If these other nodes are using an older certificate, it should still work as the previous/renewed certificate usually have overlapping active begin/expiration dates. Joseph Tam
Re: is a self signed certificate always invalid the first time?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 18 Aug 2017, voy...@sbt.net.au wrote: BUT, for a public web server where https is becoming mandatory, I'd still need a certificate from a recognized publisher, to avoid users geting 'warnings', is that so ? As Michael wrote already, it's the same vor all SSL certificates, because the underlying mechanism is the same. - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEVAwUBWZakenz1H7kL/d9rAQLV7ggAqgiz+7ttcsu4/JAHExarvu+aovhNk+Lp OqzdlME8tSnEzKUfeHmkgXR2AMAOiET4HvsU0HWsm9zwyZ24Lgxo+mJ2lN6317H2 /nlNuQDImgDB8BLTarUpucVpp7R2ppXeuy+8TPyAmagZo6kR8okkFHoMzQSDHleG gPjoBDVHq0FH6WYq25u2ts7l6L+FKEinX5T/b2hcIqnTgM129E/ak1gYZWmQm9+S bM29aHNnpV/B8uPhACXruTV3DFWW2s9wIgopgHKA0XH4g7p3DYeiXFUTyZ+e9kNN oabc56sQSd4QASpEBjsOPd8Sx3pZtiXzxZnb3yLIhjyCilwNLZA8xw== =Phs1 -END PGP SIGNATURE-
Re: is a self signed certificate always invalid the first time
On Fri, 18 Aug 2017 00:24:39 -0700 (PDT) Joseph Tamwrote: > Michael Felt writes: > > >> I use acme.sh for all of my LetsEncrypt certs (web & mail), it is > >> written in pure shell script, so no python dependencies. > >> https://github.com/Neilpang/acme.sh > > > > Thanks - I might look at that, but as Ralph mentions in his reply - > > Let's encrypt certs are only for three months - never ending circus. > > I wouldn't characterize it as a circus. Once you bootstrap your first > certificate and install the cert-renew cron script, it's not something > you have to pay a lot of attention to. I have a few LE certs in use, > and I don't think about it anymore: it just works. > > The shorter cert lifetime also helps limit damage if your certificate > gets compromised. > > Joseph Tam Obviously you do not use clustered environments with more than one node per service. Else you would not call it "it just works", because in fact the renewal is quite big bs as one node must do the job while all the others must be _offline_. -- Regards, Stephan
Re: is a self signed certificate always invalid the first time?
On 8/18/2017 9:12 AM, voy...@sbt.net.au wrote: On Fri, August 18, 2017 5:02 pm, Michael Felt wrote: On 8/11/2017 1:29 PM, Ralph Seichter wrote: And, Ralph, I salute you. I have never been able to be disciplined enough to be my own CA. I encourage you to look into the subject again. I actually have been, which is why I could give a near sensible reply. Thanks for the encouragement! With the advent of Let's Encrypt, free certs for the masses have become a thing, but if you need more than 3 months validity, want to create certs for Intranet-devices (routers, local servers), or just want maximum control over all certs, setting up your own CA is rewarding. While you're at it, no gentleman should not be without DNSSEC, DKIM and DANE these days. ;-) I should know all three, but, sadly, only one: two things to add to my list of things to research. I have been reading this with some interest (while trying to migrate Dovecot, Postfix etc..) BUT, for a public web server where https is becoming mandatory, I'd still need a certificate from a recognized publisher, to avoid users geting 'warnings', is that so ? (I'm currently using self issued for both mail and web) Above - Ralph added: I also made my CA certs available for public download, so tech-savvy users can import the CA certs manually. Depending on your site-popularity (aka number of "random" users) you could also instruct them how to access your signing key. Once they had that, they would auto-magically, recognize any other keys you signed with your CA "roots". In other words, if the work to you to instruct users to use your CA is more expensive than using a commercial CA - save money and use a commercial CA. Before spending any money on a commercial CA - look at alternatives such as Let's Encrypt. I am also looking at http://www.cacert.org/ (That might be something for you Ralph!) thanks, V
Re: is a self signed certificate always invalid the first time
Michael Feltwrites: I use acme.sh for all of my LetsEncrypt certs (web & mail), it is written in pure shell script, so no python dependencies. https://github.com/Neilpang/acme.sh Thanks - I might look at that, but as Ralph mentions in his reply - Let's encrypt certs are only for three months - never ending circus. I wouldn't characterize it as a circus. Once you bootstrap your first certificate and install the cert-renew cron script, it's not something you have to pay a lot of attention to. I have a few LE certs in use, and I don't think about it anymore: it just works. The shorter cert lifetime also helps limit damage if your certificate gets compromised. Joseph Tam
Re: is a self signed certificate always invalid the first time?
On Fri, August 18, 2017 5:02 pm, Michael Felt wrote: > On 8/11/2017 1:29 PM, Ralph Seichter wrote: >>> And, Ralph, I salute you. I have never been able to be disciplined >>> enough to be my own CA. >> I encourage you to look into the subject again. >> > I actually have been, which is why I could give a near sensible reply. > Thanks for the encouragement! > >> With the advent of Let's >> Encrypt, free certs for the masses have become a thing, but if you need >> more than 3 months validity, want to create certs for Intranet-devices >> (routers, local servers), or just want maximum control over all certs, >> setting up your own CA is rewarding. While you're at it, no gentleman >> should not be without DNSSEC, DKIM and DANE these days. ;-) > I should know all three, but, sadly, only one: two things to add to my > list of things to research. I have been reading this with some interest (while trying to migrate Dovecot, Postfix etc..) BUT, for a public web server where https is becoming mandatory, I'd still need a certificate from a recognized publisher, to avoid users geting 'warnings', is that so ? (I'm currently using self issued for both mail and web) thanks, V
Re: /var/run/dovecot permission issues
On 8/17/2017 7:07 PM, Larry Rosenman wrote: In /usr/local/etc/dovecot/conf.d/90-plugin.conf: It should be enough to just set permissions as other options are defaults. /usr/local/etc/dovecot/conf.d/10-master.conf : service stats { fifo_listener stats-mail { mode = 0666 } fifo_listener stats-user { mode = 0666 } unix_listener stats { mode = 0666 } } BTW I'm not sure if write permissions on 'stats-user' and 'stats' listeners are required for metrics service. At least I have no evidence if Dovecot ever tried to write to that listeners. Probably it is enough to set write permissions on 'stats-mail'.
Re: is a self signed certificate always invalid the first time?
On 8/11/2017 1:29 PM, Ralph Seichter wrote: On 11.08.2017 11:36, Michael Felt wrote: This is what Ralph means when he says "have been running a CA for 15+ years" - not that he is (though he could!) sell certificates commercially - rather, he is using an initial certificate to sign later certificates with. Actually, I do sell certificates to my customers. :-) In small numbers, and only for servers to which I have administrative access. So, not really "selling", but an additional service. I created a root CA and two intermediate CAs (one each for client and server certs, respectively). It would be great to have my CAs added to Mozilla's NSS root certificate store, but alas, the effort to get there is massive. Where possible, I will add my CA certs to the customers' keystores. I also made my CA certs available for public download, so tech-savvy users can import the CA certs manually. Again, technically, there is no difference in a self-signed 2048-bit RSA key, and one signed by a "major" CA. However, in the "ease of use" there may be major differences. In 2015 I rolled out an updated CA which I have used ever since, with 4096 bit keys for root and intermediary CA certs. I also only generate 4096 bit keys for servers these days, so my cert chain is "stronger" than those of some commercial CAs. Also, it is good to know that these certs have never been touched by anybody but myself. I even install my own CA cert chain on my iOS devices. And, Ralph, I salute you. I have never been able to be disciplined enough to be my own CA. I encourage you to look into the subject again. I actually have been, which is why I could give a near sensible reply. Thanks for the encouragement! With the advent of Let's Encrypt, free certs for the masses have become a thing, but if you need more than 3 months validity, want to create certs for Intranet-devices (routers, local servers), or just want maximum control over all certs, setting up your own CA is rewarding. While you're at it, no gentleman should not be without DNSSEC, DKIM and DANE these days. ;-) I should know all three, but, sadly, only one: two things to add to my list of things to research. -Ralph
Re: is a self signed certificate always invalid the first time?
On 8/11/2017 11:44 AM, Florian Beer wrote: On 2017-08-11 11:36, Michael Felt wrote: I have looked at let's encrypt. Key issue for me is having to add a lot python stuff that would otherwise not be on any server. I use acme.sh for all of my LetsEncrypt certs (web & mail), it is written in pure shell script, so no python dependencies. https://github.com/Neilpang/acme.sh Thanks - I might look at that, but as Ralph mentions in his reply - Let's encrypt certs are only for three months - never ending circus.
Re: v2.2.32 release candidate released
On 18 Aug 2017, at 2.25, Joseph Tamwrote: > >> a CREATE noselectbox/ >> --> With this change it's the same as CREATE "noselectbox" = will become >> selectable. >> >> or >> >> a CREATE noselectbox/childbox >> b DELETE noselectbox/childbox >> --> noselectbox is left behind. With this change it will be auto-deleted. > > So, does that mean empty folders will be auto-deleted, or this wouldn't > affect them? Selectable folders won't be auto-deleted, only \NoSelect folders that have no child folders. This auto-deletion is also done if LIST notices them. Actually the main reason it was implemented now was because with NFS if a folder is open while it's deleted, it could leave .nfs* files in the directory and prevent finishing the deletion. So a folder deletion would change it into a \NoSelect folder, but not delete it entirely. This is mainly a user-visible problem if the new ITERINDEX feature is used.