Closed Bug 1628600 Opened 4 years ago Closed 4 years ago

Can't move IMAP folders: "Renaming not supported across conflicting directory permissions"

Categories

(MailNews Core :: Networking: IMAP, defect)

defect

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: psychonaut, Unassigned)

Details

For at least one of my IMAP accounts, it's not possible to move certain folders using Thunderbird 68.6.0 (64-bit GNU/Linux). When I try to do so, Thunderbird pops up the following system notification:

[CANNOT] Renaming not supported across conflicting directory permissions (0.006 + 0.000 + 0.005 secs).

(The last three numbers vary from notification to notification.)

A cursory web search for this error suggests that the problem may be with directory permissions on the server, which is running Dovecot. However, two pieces of evidence would appear to discount this explanation:

  1. My sysadmin has checked the permissions for my folders on the mail server and insists that everything is in order.

  2. I have no problem moving the same folders using a different IMAP client, Claws Mail 3.17.5.

There doesn't appear to be any commonality in which mail folders are affected by this problem and which aren't. (At least, I haven't noticed any pattern.) The problem occurs even when Thunderbird is started in safe mode, with all add-ons disabled.

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Severity: normal → --

Re: bug 1530157 comment 24.

Not sure how Claws "moves" a folder. Maybe it creates a new one and then copies all the messages individually then deletes the original? I think tb just renames it which may trigger the server (Dovecot?) behavior.

But I think I only see this on Dovecot when the move is between different namespaces that are shared or public. Do have any of these?

I also don't see any permission conflicts in my Dovecot setup but it's tends to be very picky about this.

(In reply to gene smith from comment #2)

Not sure how Claws "moves" a folder. Maybe it creates a new one and then copies all the messages individually then deletes the original? I think tb just renames it which may trigger the server (Dovecot?) behavior.

From examining the logs on my own Dovecot server, it seems you're right on both counts. Claws Mail creates a new folder, copies the messages over, and deletes the original, but Thunderbird just renames the folder.

But I think I only see this on Dovecot when the move is between different namespaces that are shared or public. Do have any of these?

Not as far as I know.

(In reply to Tristan Miller from comment #3)

(In reply to gene smith from comment #2)

Not sure how Claws "moves" a folder. Maybe it creates a new one and then copies all the messages individually then deletes the original? I think tb just renames it which may trigger the server (Dovecot?) behavior.

From examining the logs on my own Dovecot server, it seems you're right on both counts. Claws Mail creates a new folder, copies the messages over, and deletes the original, but Thunderbird just renames the folder.

But I think I only see this on Dovecot when the move is between different namespaces that are shared or public. Do have any of these?

Not as far as I know.

Well, if you don't have any folders that are shared between you and other users and you have no public folders (seen by everyone) then you probably don't. They typically appear as grey top level folders with names containing "share" or "public". You can look in advance server settings of tb to see the possible names under the namespace settings.

Also, I assume you are renaming (moving) a folder within the same account?

Another thing that might cause the problem is the "ACL" setting for imap folders. See https://tools.ietf.org/html/rfc4314 and look for "rename". I think you to have "delete" and "create" imap ACL set on the source and destination folder to rename it. Tb doesn't list the ACLs in the folder properties. To see the folder properties in TB you have to create and look at an IMAP:5 log as described here: https://wiki.mozilla.org/MailNews:Logging. I don't know if you can see this in the Dovecot log, but maybe.
More info on how dovecot configures ACL is here: https://doc.dovecot.org/settings/plugin/acl/

I can look at the tb imap log if you can't interpret it. Just attach it using button above. Make sure you record your activities while moving a folder.

(In reply to gene smith from comment #4)

Also, I assume you are renaming (moving) a folder within the same account?

Yes.

Another thing that might cause the problem is the "ACL" setting for imap folders. See https://tools.ietf.org/html/rfc4314 and look for "rename". I think you to have "delete" and "create" imap ACL set on the source and destination folder to rename it. Tb doesn't list the ACLs in the folder properties. To see the folder properties in TB you have to create and look at an IMAP:5 log as described here: https://wiki.mozilla.org/MailNews:Logging. I don't know if you can see this in the Dovecot log, but maybe.
More info on how dovecot configures ACL is here: https://doc.dovecot.org/settings/plugin/acl/

I can look at the tb imap log if you can't interpret it. Just attach it using button above. Make sure you record your activities while moving a folder.

I don't think that my mail server supports ACL rights, since ACL isn't listed among the capabilities, and trying to run ACL commands like LISTRIGHTS and GETACL fail with an "Unknown command" error:

$ telnet mail 143
Trying 193.171.142.181...
Connected to mail.
Escape character is '^]'.
* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ STARTTLS AUTH=CRAM-MD5 AUTH=PLAIN AUTH=LOGIN] Dovecot (Debian) ready.
a LOGIN tristan "[password-redacted]"
a OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS BINARY MOVE SNIPPET=FUZZY LITERAL+ NOTIFY SPECIAL-USE] Logged in
a GETACL "ODR proposal"
a BAD Error in IMAP command GETACL: Unknown command (0.001 + 0.000 secs).

The Thunderbird log doesn't seem to have any ACL information either. Below is an excerpt showing me trying (and failing) to move a folder.

2020-08-14 09:17:43.821772 UTC - [(null) 14850: Main Thread]: D/IMAP proposed url = ODR proposal folder for connection ODR proposal has To Wait = false can run = true
2020-08-14 09:17:43.822778 UTC - [(null) 14850: Unnamed thread 0x7f150f9df040]: I/IMAP 0x7f15092be800:fichte.ofai.at:S-ODR proposal:SendData: DONE
2020-08-14 09:17:43.824539 UTC - [(null) 14850: Unnamed thread 0x7f150f9df040]: D/IMAP ReadNextLine [stream=0x7f15097e4780 nb=55 needmore=0]
2020-08-14 09:17:43.824548 UTC - [(null) 14850: Unnamed thread 0x7f150f9df040]: I/IMAP 0x7f15092be800:fichte.ofai.at:S-ODR proposal:CreateNewLineFromSocket: 14 OK Idle completed (15.652 + 15.651 + 15.651 secs).
2020-08-14 09:17:43.824623 UTC - [(null) 14850: Unnamed thread 0x7f150f9df040]: I/IMAP 0x7f15092be800:fichte.ofai.at:S-ODR proposal:ProcessCurrentURL: entering
2020-08-14 09:17:43.851894 UTC - [(null) 14850: Unnamed thread 0x7f150f9df040]: I/IMAP 0x7f15092be800:fichte.ofai.at:S-ODR proposal:ProcessCurrentURL:imap://tristan@fichte.ofai.at:993/movefolderhierarchy%3E%5EODR%20proposal%3E%5EArchives.proposals:  = currentUrl
2020-08-14 09:17:43.852568 UTC - [(null) 14850: Unnamed thread 0x7f150f9df040]: I/IMAP 0x7f15092be800:fichte.ofai.at:S-ODR proposal:SendData: 15 list (subscribed) "" "ODR proposal.*" return (special-use)
2020-08-14 09:17:43.864288 UTC - [(null) 14850: Unnamed thread 0x7f150f9df040]: D/IMAP ReadNextLine [stream=0x7f15097e4780 nb=52 needmore=0]
2020-08-14 09:17:43.864301 UTC - [(null) 14850: Unnamed thread 0x7f150f9df040]: I/IMAP 0x7f15092be800:fichte.ofai.at:S-ODR proposal:CreateNewLineFromSocket: 15 OK List completed (0.010 + 0.000 + 0.010 secs).
2020-08-14 09:17:43.864887 UTC - [(null) 14850: Unnamed thread 0x7f150f9df040]: I/IMAP 0x7f15092be800:fichte.ofai.at:S-ODR proposal:SendData: 16 close
2020-08-14 09:17:43.866704 UTC - [(null) 14850: Unnamed thread 0x7f150f9df040]: D/IMAP ReadNextLine [stream=0x7f15097e4780 nb=45 needmore=0]
2020-08-14 09:17:43.866708 UTC - [(null) 14850: Unnamed thread 0x7f150f9df040]: I/IMAP 0x7f15092be800:fichte.ofai.at:S-ODR proposal:CreateNewLineFromSocket: 16 OK Close completed (0.001 + 0.000 secs).
2020-08-14 09:17:43.866892 UTC - [(null) 14850: Unnamed thread 0x7f150f9df040]: I/IMAP 0x7f15092be800:fichte.ofai.at:A:SendData: 17 rename "ODR proposal" "Archives.proposals.ODR proposal"
2020-08-14 09:17:43.874553 UTC - [(null) 14850: Unnamed thread 0x7f150f9df040]: D/IMAP ReadNextLine [stream=0x7f15097e4780 nb=110 needmore=0]
2020-08-14 09:17:43.874556 UTC - [(null) 14850: Unnamed thread 0x7f150f9df040]: I/IMAP 0x7f15092be800:fichte.ofai.at:A:CreateNewLineFromSocket: 17 NO [CANNOT] Renaming not supported across conflicting directory permissions (0.007 + 0.000 + 0.006 secs).

Thanks for checking the lack of ACL capability. So that's not the problem, good to know.
You seem like a well informed tb user so maybe you have seen this link, https://bit.ly/2Y2kdKe , or similar items by searching for "Renaming not supported across conflicting directory permissions".
Other than that the long ago TB design decision was to implement folder moves using rename, the error is not directly caused by TB but is a file permission issue with your dovecot setup. The link provides some things to look for. I know you said your sys-admin has checked file permission but maybe the advice here is something that was overlooked? Let me know what you find.

I've since found that I have shell access to my own IMAP folders on the server, and have just now confirmed for myself that there are conflicting directory permissions for the folders I'm trying to move. I suppose our sysadmin may have overlooked this. Changing the directory permissions so that they match solves the issue. So this isn't a Thunderbird bug at all. Sorry for having wasted your time!

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.