Solutions to miscellaneous problems

NFS Mount hanging


If 'mount' hangs, check the following:
  1. 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
    in logs.
    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.
  2. 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: 
      rpc.mountd: authenticated 
     mount request from chlamydia.gunk.org:650 
     for /backup (/backup)
    Also check for stupid mistakes like trying to export a disk that is not mounted on the server.
  3. 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.

Solution: 
    cd /etc/rc.d/rc3.d
    ln -s ../local S23local
    cd ..
Create file named 'local' with /usr/sbin/netdate, make it executable

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'.

Solution:

  1. 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).
  2. 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).
  3. Temporarily change the command 
         print command = /usr/bin/lpr -P%p %s
    to 
         print command = logger %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.
  4. 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.
  5. Next check /etc/lpd.perms and /etc/lpd.conf. Make sure lpd.perms contains only two lines: 
         ACCEPT SERVICE=C
     DEFAULT ACCEPT
    Restart lpd to make it read the new config file: 
         /etc/rc.d/lpd reload
  6. 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.
  7. 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.
  8. 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: 
        IF filter 'if' filter msg - '/usr/lib/lpdfilter/bin/if: \
    /usr/lib/lpdfilter/filter/unpjl: No such file or directory'
    you need to find the unpjl file, make it executable, and install it in its correct location, e.g., 
        cd /usr/lib/lpdfilter/filter 
    cp ../bin/unpjl .
  9. 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           /dev/console
    or higher.
  10. Notice that Windows still may give a bogus "Access Denied" message, even though printing now works. That is somebody else's problem.

See also Samba authentication problems and Can't print using lprng.

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=63.127.146.216:\
	: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=63.127.146.216:\
	:rp=print:\
	:sh:\
	:bk:\
	:filter=/usr/libexec/filters/lpf:\
	:sd=/var/spool/lpd/canon:\
	:lf=/var/spool/lpd/canon/errs:\
	:mx#0:
The same problem occurred when lpf was replaced with a new filter called 'ifhp'. Although it is listed on the lprng website, ifhp is a separate utility. It seems to only be available as RPMs; however, running 'rpm -i' on the source rpm creaetd a .tgz file in /usr/src/packages/SOURCES which chould be checked and compiled normally. It installs itself in /usr/local/libexec/filters by default unless you specify 'configure --prefix=/usr'.

Compiling lprng: lprng compiles cleanly in Suse linux, but there are several tricks to be aware of:

  1. Use 'configure --prefix=/usr', otherwise it will install in /usr/local.
  2. 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.
  3. Several files are used by lprng that may be unfamiliar to BSD lpr users: 
             /etc/lpd/lpd.perms
         /etc/lpd/lpd.conf
         /etc/printcap  (changes in format)
         /usr/libexec/filters/lpf
    (note new location for lpf).
  4. Note that most old lpf scripts for lpr no longer work. The new lpf is a compiled executable.
Back