Solutions to miscellaneous problems
NFS Mount hanging
If 'mount' hangs, check the following:
- System load goes to 1. Can't regain access
to the terminal after issuing mount command.
nfs_get_root: getattr error = 5 portmap: server localhost not responding, timed out
Solution: NFS server had only 4 threads and 4 clients were already connected. Unmount one of the other clients or edit /etc/sysconfig/nfs and increase USE_KERNEL_NFSD_NUMBER="4" to 8, and restart NFS server.
- Mount works for some computers but not others Check routing.
In some versions of Linux the default route is specified in
/etc/sysconfig/networks/route. Make sure the computers can ping each other
and that name lookups are working. Make sure communication is not blocked
in /etc/hosts.allow, iptables, or by your router's firewall. If there are
no messages in your syslogs, this should be the first thing to test.
A successful connection should always give a message like:
Also check for stupid mistakes like trying to export a disk that is not mounted on the server.
rpc.mountd: authenticated mount request from chlamydia.gunk.org:650 for /backup (/backup)
- rpc.mountd: getfh failed: Operation not permitted This could mean there is some problem in /etc/exports, such as an invalid hostname. Fixing the exports file is not sufficient; you must also stop and start /etc/rc.d/nfsserver ('restart' doesn't always work).
Date is wrong after reboot
Problem: Date is wrong after reboot.
cd /etc/rc.d/rc3.d ln -s ../local S23local cd ..
Open Office crashing at startup
Problem: Open Office crashes at startup.
Solution: This is caused by installing Open Office as root instead of as a regular user. If the installed files for root's copy of Open Office are in the path for a regular user, it will crash. This is caused by a peculiarity in the installation script. Delete all the OO files, remove Open Office from path, and reinstall as a regular user.
OpenSSH ssh client hangs at exit when a background process is started
This section has been moved.
Printing from Windows 2000 to lprng through Samba
Problem: Printing from Windows 2000 over Samba gives "Access denied, unable to connect" message on Windows side. Printing works with BSD-style printing but not with 'lprng'.
- Temporarily change the permissions in /var/spool/lpd to 777 (note that this change is not permanent, because lprng changes them back to 600 whenever you restart it).
- Check the directory permissions on /var, /var/spool, and /var/spool/lpd. The process that uses those files must have execute permission on all paths leading to the file (as well as whatever permissions it needs to act on the file itself).
- Temporarily change the command
print command = /usr/bin/lpr -P%p %s
in /etc/samba/smb.conf. This will tell you whether the data is reaching Samba or not, and what arguments it is using. The Samba share name for the printer must be the same as the printcap name (e.g., "lp"). You can't have a printer share named "Lexmark", for example, in smb.conf that refers to a printer named "lp". The error message in this case is bogus. It is not a permission problem but a printer ID problem.
print command = logger %p %s
- If the problem persists, the next step is to try temporarily changing the guest account in smb.conf from 'ftp' to a real user name who is known to be able to print.
- Next check /etc/lpd.perms and
/etc/lpd.conf. Make sure lpd.perms
contains only two lines:
Restart lpd to make it read the new config file:
ACCEPT SERVICE=C DEFAULT ACCEPT
- Edit /etc/samba/smb.conf and make sure the path to the printer spool is correct. A particularly sneaky problem is when you have one computer with /usr/spool/lpd and another with /var/spool/lpd, and you get them mixed up. If the path is wrong, there will be no error messages and nothing shows up in log.smbd.
- At this point, your Samba print jobs should at least show up in the queue. They might, however, sit in the queue forever without being printed.
- Check /var/spool/lpd/lp/status.lp
(or whatever the corresponding file is on your system)
and look for differences in the status when you print from the
command line compared with the status when you print from Windows. If
you have a message like:
you need to find the unpjl file, make it executable, and install it in its correct location, e.g.,
IF filter 'if' filter msg - '/usr/lib/lpdfilter/bin/if: \ /usr/lib/lpdfilter/filter/unpjl: No such file or directory'
cd /usr/lib/lpdfilter/filter cp ../bin/unpjl .
- The next step is to get rid of the endless "connection
from localhost" messages. If restarting lpd doesn't help, change
the appropriate line in /etc/syslog.conf to
- Notice that Windows still may give a bogus "Access Denied" message, even though printing now works. That is somebody else's problem.
Problem: Unable to print from samba, even though lpr works.
Solution: This was a problem with the new lprng (3.8.27 and 3.8.28). The lpf filter included with lprng failed to work with samba print jobs for an unknown reason. Removed the line and created separate print spools for Unix and Windows users. Here is the relevant section of /etc/printcap:
# for windows canon:\ :lp=:/dev/null:\ :force_localhost:\ :rm=126.96.36.199:\ :rp=print:\ :sh:\ :bk:\ :sd=/var/spool/lpd/canon:\ :lf=/var/spool/lpd/canon/errs:\ :mx#0: # for linux canon2:\ :lp=:/dev/null:\ :force_localhost:\ :rm=188.8.131.52:\ :rp=print:\ :sh:\ :bk:\ :filter=/usr/libexec/filters/lpf:\ :sd=/var/spool/lpd/canon:\ :lf=/var/spool/lpd/canon/errs:\ :mx#0:
Compiling lprng: lprng compiles cleanly in Suse linux, but there are several tricks to be aware of:
- Use 'configure --prefix=/usr', otherwise it will install in /usr/local.
- The installation places config files in a number of unusual places, including /usr/etc and /usr/etc/lpd. In the interest of maintainability, these should be moved to /etc (for printcap) and /etc/lpd (for lpd.conf) and the originals replaced with soft links.
- Several files are used by lprng that may be unfamiliar to BSD lpr users:
(note new location for lpf).
/etc/lpd/lpd.perms /etc/lpd/lpd.conf /etc/printcap (changes in format) /usr/libexec/filters/lpf
- Note that most old lpf scripts for lpr no longer work. The new lpf is a compiled executable.