I am using dovecot 1.0.rc15 (a similar problem occurred in rc10) on Solaris 9 (sparc). When working with a user who's home dir is on a local disk everything seems fine. But when that home is on an NFS-mounted disk things are very badly awry.
Both the indices and the subscriptions file are being destroyed and what is left behind are files with names of the form .nfs72C034 etc. These files are described in the shell script nfsfind - every Solaris system ships with a root cron to run nfsfind and delete stale files:
# These files are created by NFS clients when an open file # is removed. To preserve some semblance of Unix semantics # the client renames the file to a unique name so that the # file appears to have been removed from the directory, but # is still usable by the process that has the file open.
I dont't see why dovecot would be unlink'ing it's active files while running - but I actually managed to see the dovecot.index.log appear briefly and then change to a .nfsXXXX file during the test user login.
dovecot.index always seems to exist correctly but from local tests I know there should be a dovecot-uidlist, dovecot.index.cache, dovecot.index.log too, and these all appear to be .nfsXXXX files
I can't seem to find anything relating to this specific problem in the archives, although these files have been mentioned a few times. And yes I do have mmap_disable = yes (but that is only relevant to the indexes, and the same thing is happening to the subscriptions file - ie some common library code for dealing with files has an issue)
I should also note that these NFS mounts have been in existence for years and lots of things are running through them, so there shouldn't be anything wrong there.
Suggestions, please?
Thanks,
John Harper
Senior Systems Administrator Information and Instructional Technology Services University of Toronto Scarborough harper@utsc.utoronto.ca