Basics of my setup:
- vpopmail 5.4.6 (I'll upgrade once I'm done inflicting pain on myself in other ways)
- NFS mounted home directories provide access to the /home/vpopmail directory. Another NFS volume provides /home/vpopmail/domains. Those are mounted on my 2 mail servers.
- I have "maproot=vpopmail" on the domains mount, so even if I do stuff as root - the permissions stay correct as vpopmail:vchkpw.
- NFS connectivity is local, over 100mbit switch.
When the problem first started, it manifested itself as the error "Unable to chdir to vpopmail/domains" when I would run 'vadddomain -r8 testdom.com'. Naturally I *could* chdir to /home/vpopmail/domains - I even wrote a tiny c program and tried it as all the various uid's. No dice.
Only after running vadddomain under gdb (props to you guys for keeping '-g' in the CFLAGS), was I able to figure out that the call to next_big_dir in vadddomain returned "/home/vpopmail/domains/.dir-control", and so DomainSubDir was being set to "/home/vpopmail/domains/.dir-control/testdom.com". Obviously, that doesn't fly to calls to mkdir().
I ended up restoring my .dir-control file from backups, and things appear to be back to normal.
What would have really helped me would have been any of the following:
- A call to perror() after failed mkdir() / chown calls. Not checking those return values was what bubbled up into a cryptic, misleading error message.
- In r_mkdir, testing that tmpbuf either exists and is a directory, or doesn't exist. If its a file / link / pipe / whatever, then things should explode.
Sadly, I don't have time to put together a patch at this time.
Regards, -- Dave Steinberg http://www.geekisp.com/ http://www.steinbergcomputing.com/
