Hide Forgot
First, I doubt that this is a problem with mutt, but rather with the NFS locking, but I was not able to verify this yet, so am starting with mutt, which is the only program with which I had this problem until now. The /home/common partition is mounted via NFS. With a plain RedHat 6.1 install, if I access any mailbox which resides within this partition, mutt is unable to lock it: If no NFS daemon is started on the local host (my default), I get the following strace: open("/home/common/benjamin/Mail/igg", O_RDONLY) = 3 SYS_175(0, 0x80a1320, 0, 0x8, 0) = 0 fcntl(3, F_SETLK, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = -1 ENOLCK (No locks available) and mutt writes out an appriopriate error message (sometimes it gets overwritten at once by some other status messages, so it is not always visible, but you can hear the bell, too). If I start /etc/rc.d/init.d/nfs (I tried this, due to some seemingly unrelated tips to other NFS problems) the behaviour changes: I can see the status line "Waiting for fcntl lock... 1" which counts in second-steps up to 5 and finally I get the message "Timeout exceeded while attempting fcntl lock", which corresponds with the following strace: open("/home/common/benjamin/Mail/igg", O_RDONLY) = 3 SYS_175(0, 0x80a8848, 0, 0x8, 0) = 0 fcntl(3, F_SETLK, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = -1 EACCES (Permission denied) fstat(3, {st_mode=0, st_size=0, ...}) = 0 brk(0x80c5000) = 0x80c5000 write(1, "\r\33[30m\33[47mWaiting for fcnt"..., 53^MESC[30mESC[47mWaiting for fcntl lock... 1ESC[KESC[39;49mESC[m^O) = 53 Some notes: - the problem seems to be NFS related: if I do sudo cp -a /home/common/benjamin /home/common, the problem is gone - the rights on my mailboxes seem to be ok: I have no problem to read the same folder with the same version of mutt with a RedHat 5.2 (somewhat updated, but no core packackes, I think) install, - this also seems to show, that the server does it job correctly. System: - RedHat 6.1 with minor updates (but also tried it with a plain install), I think I also already tested it with 6.2 (with same symptom), but I am not sure anymore, so if this important, say so and I will try again. Also, if you need more infos about versions / packages - maybe because they are not as obvious as I think - please just say what I should provide. - the NFS server has knfsd-1.2.2-4 installed and is based on RedHat 6.1, I think. - mutt is 1.0.1i-6 installed from RedHat 6.2 (but also tested with earlier version... upgraded to check whether the problem was already fixed)
You need to have the nfslock service started on both the client and the server for NFS locking to work correctly.
Sorry to come back to you so late, but I partially had to wait for feedback from my administrator. By the way, I think the resolution "NOTABUG" is not correct, because nfslock was not only not started, but also not installed at all, although I have several NFS mounted devices. The problem that I have now is that the server does not run a knfsd, but a user space one (because it had stability problems which the user space one solved, AFAIK), and nfslock seem to only be thought for knfsd. Well, the server administrator refuses to switch back to knfsd. But I guess, it must be possible somehow to "connect" also with a 6.1 system, when a 5.2 system has no problem at all. If I am not wrong, the "solution" of the 5.2. system was that locking did not really lock the stuff. Am I correct? If so, I would be happy with a similar solution for 6.1, because there will be no concurrent accesses. Do you have any suggestions for me? Thank you for your attention.