FreeBSD Problems

This page is a record of odd problems I've encountered during administration of FreeBSD.

Oct 30 19:14:15 users sshd[95824]: _secure_path: cannot stat /home/munk/.login_conf: Permission denied

This error occured after changing the permissions on the home directories of users on my system. I modified the permissions on all user's home directories to 0701 to stop users from changing into other user's directories to snoop around. However an unfortunate side-effect was that a wheel user account was no 'broken'.

Symptoms included:

  1. error messages on the root console such as in the title above (Oct 30 19:14:15 users sshd[95824]: _secure_path: cannot stat /home/munk/.login_conf: Permission denied)
  2. shell environment messed up because the shell rc files, .cshrc and .cshrc-local were not being read, with error messages of 'permission denied' when as the wheel user I tried to execute 'source .cshrc' (even though the wheel user owned the file and permissions were set to 755)

Solution:

It turned out I had accidentally set the permissions on the dir /home itself (as well as on each of the user's home directories). For this reason I think (fairly sure!) that the login capabilities config file, .login_conf, could not be read correctly - I think it needed wheel group permissions of greater than 0 to be read.

Lesson learnt (again!) from this was to 'script' all changes to permissions very carefully, including a full 'ls -al' of all the directories/files whose permissions were about to be changed before actually changing them. This way if something goes wrong, the script file can always be checked if something goes wrong and permissions need to be changed back to their original setting.

Nov 11 20:15:31 users proftpd[14668]: no modules loaded for `ftpd' service
Nov 11 20:15:31 users /kernel: Nov 11 20:15:31 users proftpd[14668]: no modules loaded for `ftpd' service

This error happens after proftpd is installed and a user logs in via ftp.

Symptoms included:

  1. error messages on the root console such as in the title above (Nov 11 20:15:31 users proftpd[14668]: no modules loaded for `ftpd' service Nov 11 20:15:31 users /kernel: Nov 11 20:15:31 users proftpd[14668]: no modules loaded for `ftpd' service)
  2. Users can login via ftp even though the error messages are logged as above

Solution:

The solution is simple to add the following line to your configuration file for proftpd, /usr/local/etc/proftpd.conf:

AuthPAM off

By default on FreeBSD 4.7 it seems that proftpd does not have to use PAM to authenticate users and the errors are suppressed if PAM is not used

Windows 2000 / win2k server unable to connect to FreeBSD Samba server

An irritating problem occured whereby I couldn't connect to the FreeBSD Samba share from my win2k machine after I'd implemented a set of IPF rules.

Symptoms included:

  1. Error in win2k about the freebsd host / share not being found
  2. Obviously attempting to open files on the freebsd share would timeout

Solution:

The solution was to add a rule to /etc/ipf.rules to allow inbound traffic to the broadcast address for my network.

When attempting to lookup a NetBIOS hostname from win2k, the win2k machine will send a broadcast message to every machine that it knows about on it's network using UDP port 137 in an attempt to resolve the NetBIOS host name to an IP address. In my case this is every machine in the network 213.152.51.192/29, which is to say it sends out a broadcast address to 213.152.51.199 (which will be recieved by every machine from 213.152.51.193 through 213.152.51.198 as I understand network broadcast addressing.

The problem in my case was that, although I had setup the following rule in IP Filter to allow in all traffic from 213.152.51.192/29:

pass in quick on fxp0 from 213.152.51.192/29 to 213.152.51.194

this rule did not allow in connections on the broadcast address 213.152.51.199. (I managed to work this out by running a packet sniffer - snort - noticing that when I tried to look up the share in win2k, several packets were received by 213.152.51.194 but blocked because the receipt address was actually 213.152.51.199.

In short then, the solution was to add the following rule to my IPF ruleset:

pass in quick on fxp0 from 213.152.51.192/29 to 213.152.51.199

References

http://www.snort.org
http://www.snort.org
http://munk.me.uk/ipf/

Feb 23 00:12:15 darkstar sm-msp-queue[249]: h1N4gFo3099166: to=postmaster, delay=00:29:59, xdelay=00:00:00, mailer=relay, pri=123113, relay=darkstar.munk.nu, dsn=4.0.0, stat=Deferred: Operation timed out with darkstar.munk.nu.

This is a very ugly problem and took me the best part of a day to figure out with the help from a mailing list item. I nearly passed out when the hack suggested in that mail worked straight off and am indebted to Gary W. Swearingen for posting his solution.

Symptoms included:

  1. when sending mail locally from a shell - or when web applications attempt to send mail using the local sendmail mta
    - the error message 'stat=Deferred: Operation timed out with <fully qualified host name> occurs
  2. outgoing mail to a remote server works fine - ie from a shell to a user on another domain
  3. mail is accepted coming into the server from another host on the same domain ok as well

Solution:

The solution, as outlined here is to modify the following line in the /etc/mail/freebsd.submit.mc file so it looks like this:

FEATURE(`msp',`[127.0.0.1]')

Once done, build the .cf files from the .mc files and install them using:

cd /etc/mail
make install
(see /etc/mail/Makefile for details)

and finally restart the mailer using:

make restart

I found this trick worked first time and a stack of deferred mails shot out of the client queue. Job's a good un.

munk