[Dovecot] Dovecot cannot unlink non-empty directory
Hi,
Currently I use dovecot 1.1.3 on Debian Testing. CPU arch is x86. Mail is stored on ext3 fs.
I'm having a following problem with deleting folders (there is no problem with creation of folders):
Error: IMAP(test@laptop.aonet.pl): unlink_directory(/home/vpopmail/domains/laptop.aonet.pl/test/.//Maildir/..DOVECOT-TRASHED) failed: Permission denied
HOW TO REPRODUCE
- Create a fresh new account
- Login to a new account and create folder say 'TestFolder'
- When I try to delete TestFolder - it is deleted and ..DOVECOT-TRASHED appears in user's Maildir AND
Error: IMAP(test@laptop.aonet.pl): unlink_directory(/home/vpopmail/domains/laptop.aonet.pl/test/.//Maildir/..DOVECOT-TRASHED) failed: Permission denied
message appears - it is triggered from line 815 of dovecot-1.1.3/src/lib-storage/index/maildir/maildir-storage.c
- Create 'TestFolder2'
- Trying to delete 'TestFolder2' gives the same error:
Error: IMAP(test@laptop.aonet.pl): unlink_directory(/home/vpopmail/domains/laptop.aonet.pl/test/.//Maildir/..DOVECOT-TRASHED) failed: Permission denied
this one however, is triggered from line 806 of dovecot-1.1.3/src/lib-storage/index/maildir/maildir-storage.c
- The folder 'TestFolder2' is not deleted and from this point no other newly created folders can be deleted too.
I. Yes, the file permissions are fine - all are writeable to (mail_uid = vpopmail) II. The problem is - dovecot cannot unlink non-empty directory, I artificially deleted contents of ..DOVECOT-TRASHED and dovecot allowed folder deletion from client. After that situation was like in point 4.
-My-config------------------------------------------------------ # 1.1.3: /usr/local/etc/dovecot.conf base_dir: /usr/local/var/run/dovecot/ log_path: /dev/stderr info_log_path: /dev/stderr log_timestamp: listen: 127.0.0.1:143 ssl_listen: 0:993 ssl_cert_file: /var/qmail/control/servercert.pem ssl_key_file: /var/qmail/control/servercert.pem ssl_cipher_list: ALL:!LOW verbose_ssl: yes login_dir: /usr/local/var/run/dovecot/login login_executable: /usr/local/libexec/dovecot/imap-login verbose_proctitle: yes first_valid_uid: 89 last_valid_uid: 89 mail_uid: vpopmail mail_gid: vchkpw mail_location: maildir:~/Maildir mail_debug: yes mail_plugins: quota imap_quota imap_client_workarounds: outlook-idle auth default: user: vpopmail verbose: yes debug: yes passdb: driver: vpopmail args: quota_template=quota_rule=*:backend=%q userdb: driver: vpopmail plugin: quota: maildir quota_rule: ?:storage=110485760 quota_rule2: Trash:ignore quota_rule3: SPAM:ignore quota_warning: storage=90%% /usr/local/bin/imap-quota-warning 90
is this my mistake in configuration or is dovecot doing something wrong?
tnx for help, -Włodek
On Sun, 2008-09-14 at 16:28 +0200, Włodek Waligórski wrote:
HOW TO REPRODUCE
- Create a fresh new account
- Login to a new account and create folder say 'TestFolder'
- When I try to delete TestFolder - it is deleted and ..DOVECOT-TRASHED appears in user's Maildir AND
Error: IMAP(test@laptop.aonet.pl): unlink_directory(/home/vpopmail/domains/laptop.aonet.pl/test/.//Maildir/..DOVECOT-TRASHED) failed: Permission denied
What are those extra /.// in the middle of the path? Although I don't think it should matter. In any case this isn't normal.
I. Yes, the file permissions are fine - all are writeable to (mail_uid = vpopmail)
Some syscall fails with "Permission denied". Unfortunately unlink_directory() doesn't show which one. I thought it would always be obvious why it's failing..
II. The problem is - dovecot cannot unlink non-empty directory, I artificially deleted contents of ..DOVECOT-TRASHED and dovecot allowed folder deletion from client. After that situation was like in point 4.
unlink_directory() recursively goes through all files and directories, unlinking the files and rmdiring the directories.
You could strace the process to see which syscall exactly is failing: strace -p <imap process pid>
Timo Sirainen pisze:
What are those extra /.// in the middle of the path? Although I don't think it should matter. In any case this isn't normal.
The '/./' is used by some programs (like sftp-server) to chroot users to their home directory. It is necessary for chroot to work.
Some syscall fails with "Permission denied". Unfortunately unlink_directory() doesn't show which one. I thought it would always be obvious why it's failing.. [...] You could strace the process to see which syscall exactly is failing: strace -p <imap process pid>
indeed, it fails on open()
[...] lstat64("/home/vpopmail/domains/laptop.aonet.pl/tescior/.//Maildir/.test12234", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 rename("/home/vpopmail/domains/laptop.aonet.pl/tescior/.//Maildir/.test12234", "/home/vpopmail/domains/laptop.aonet.pl/tescior/.//Maildir/..DOVECOT-TRASHED") = -1 ENOTEMPTY (Directory not empty) open(".", O_RDONLY|O_LARGEFILE) = -1 EACCES (Permission denied) write(2, "\1E3_unlink_directory(/home/vpopma"..., 124) = 124 [...]
(the preceding "3_" on unlink_directory is my modification)
could '/./' cause this ?
-Włodek
On Mon, 2008-09-15 at 15:26 +0200, Włodek Waligórski wrote:
open(".", O_RDONLY|O_LARGEFILE) = -1 EACCES (Permission denied)
Oh. unlink_directory() tries to preserve the current directory, so it first opens it. Since it can't, it means the user doesn't have access to the process's current directory. So either
a) You're returning a home directory where the user doesn't have read access.
b) You're not returning a home directory, and user doesn't have read access to /tmp.
Timo Sirainen pisze:
a) You're returning a home directory where the user doesn't have read access.
That's the case. To be exact the mail delivery/retrieval user (vpopmail) doesn't have the read access to user's home directory.
Why does dovecot need this access? Shouldn't access to ~/Maildir suffice?
-Włodek
On Mon, 2008-09-15 at 17:53 +0200, Włodek Waligórski wrote:
Timo Sirainen pisze:
a) You're returning a home directory where the user doesn't have read access.
That's the case. To be exact the mail delivery/retrieval user (vpopmail) doesn't have the read access to user's home directory.
Why does dovecot need this access? Shouldn't access to ~/Maildir suffice?
Home directory can be used for several different things. http://wiki.dovecot.org/VirtualUsers#homedirs
If you don't have a readable home directory, you might as well not return any so Dovecot doesn't try to use it.
participants (2)
-
Timo Sirainen
-
Włodek Waligórski