(start-dccifd) su: no directory

Tom Bucacci tomb@inetct.com
Sun Jul 17 21:07:28 UTC 2005


Thanks so much for the quick response.  I tried giving the user a home
directory and shell but I was still receiving the same error.  I
deinstalled the FreeBSD port and built DCC from source.  That worked
much better and everything is running fine now.

To answer your question about my mail server, I'm using Microsoft
Exchange and I have a sendmail server running MailScanner scanning my
incoming mail and forwarding it to the Exchange box.


> From: "Tom Bucacci" 

> I installed DCC on a FreeBSD 5.4 server from the ports collection.  

Unless the garbage added to the ports version of the DCC source has been
fixed, that may have been a mistake.  Besides, when I last I heard, the
FreeBSD ports package for 5.* was disabled because of some nonsense
about library linking problems.  My own machines run FreeBSD.

The person building the port or package, I'm not sure which, recently
contacted me.  I tried to convince him to use the DCC ./configure script
instead of the crazy sed scripts to do whatever they feel is needed.
Among other things, that would let people who us the FreeBSD port use
/usr/local/dcc/libexec/updatedcc to install new verisons.
 From what he said, it might be difficult to convince the "committers"
to do things the easy and better way.

> created a symbolic link called rcDCC.sh in /usr/local/etc/rc.d/ linked

> to /usr/local/dcc/libexec/rcDCC.  When DCC tries to start I get an 
> error when starting dccifd.  The error is 'su: no directory'.  I'm not

> sure what this means or how to fix it.  Has anybody run into this

You probably did not give the "dcc" user or whatever you chose a real
shell or home directory.  The user's home directory should be /var/dcc
or whatever you make the DCC home directory.  I find it convenient to
give the dcc user a real shell so that I can do things like

    su dcc
    ci -l ids map

I like to maintain RCS archives of configuration files.  Those
particular files must be private and owned by the dcc user.

However, to help such no-shell problems, the most recent version of the
DCC source falls back on executing the daemons with -Idcc su fails.
If you had installed from source, I would suggest that you run updatedcc
to get the most recent version.  Since you used the FreeBSD port, the
updatedcc script will not have been built with your ./configure choices,
or the choices of the FreeBSD port people.

By the way, what Microsoft mail system do you use that changes the
message body of a retransmission of a message after a 4yz temporary
failure and includes a copy of the real message body as some kind of
proprietary Microsoft document format?  Your subscription confirmation
took a day or two and would have failed except that I noticed it in my
logs.  I'm working on some stuff and have been watching logs more
closely.  I use the greylisting in dccm and dccifd.  See
To foil obvious but so far unreported attacks on greylisting, by default
it requires that greylist retransmissions be identical.  The varying,
not-really-retransmissions of your subscription confirmation did not get
through until I restarted dccm with GREY_CLIENT_ARGS=weak-body in
/var/dcc/dcc_conf...or probably /usr/local/dcc/dcc_conf on your system.

Vernon Schryver    vjs@rhyolite.com

More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.