Unix Tech Tips & Tricks

Understanding the Linux Kernel · not

% rcsdiff -r1.2 xform.c
% ci -m"Fix CR 604: vary conditioning algorithm according to\
? range data supplied by caller." filter.sh
$ ci -m"Fix CR 604: vary conditioning algorithm according to
> range data supplied by caller." filter.sh
% rcsdiff -r1.2 xform.c,v % rcsdiff -r1.2 xform.c
% ci xform.c
% ci xform.c,v
% ci RCS/xform.c,v
% ci RCS/xform.c,v xform.c
% ci xform.c RCS/xform.c,v
% ci /home/cullen/current/src/mathlib/xform.c /project/archive/mathlib/xform.c,v
% ci /project/archive/mathlib/xform.c,v /home/cullen/current/src/mathlib/xform.c
% ci xform.c
% ci xform.c
xform.c,v  <--  xform.c initial revision: 1.1 enter description, terminated with ^D or '.': NOTE: This is NOT the log message! >> Matrix transform routines, for single-precision data.
>> .
done
% ci -m"As ported from 9000 engineering group sources,\
? version 4.13." xform.c
% cat > xform.desc
Matrix transform routines, for single-precision data.
^D
% ci -txform.desc xform.c
% ci -t-"Matrix transform routines, for single-precision data." xform.c
% co xform.c
xform.c,v  -->  xform.c revision 1.1 done
% co xform.c
RCS/xform.c,v  -->  xform.c revision 1.1 writable xform.c exists; remove it? [ny](n):
co error: checkout aborted
% co -l xform.c
xform.c,v  -->  xform.c revision 1.1 (locked) done
% co -l xform.c
RCS/xform.c,v  -->  xform.c co error: revision 1.1 already locked by cullen
% rcsdiff xform.c
% rcsdiff xform.c
=================================================================== RCS file: xform.c,v retrieving revision 1.1 diff -r1.1 xform.c 4a5 > j_coord = i_coord - x; 11,12c12,13 <       for (j = j_coord; j < j_max; ++j) <               if (a[j] < b[j]) { --- >       for (j = j_coord + 1; j <= j_max; ++j) >               if (a[j - 1] < b[j]) { 20d20 < j_coord = i_coord - x;
% rcsdiff -r1.3 xform.c
% rcsdiff -r1.1 -r1.2 xform.c
% ci xform.c
% ci xform.c
xform.c,v  <--  xform.c new revision: 1.2; previous revision: 1.1 enter log message: (terminate with ^D or single '.') >> In function ff1():  move declaration of j_coord; fix
>> off-by-one error in traversal loop.
>> .
done
% ci -m"In function ff1():  move declaration of j_coord; fix\
? off-by-one error in traversal loop." xform.c
% rcs -u xform.c
RCS file: xform.c,v 1.1 unlocked done
% rcs -u1.1 xform.c
RCS file: xform.c,v 1.1 unlocked done
% rlog xform.c RCS file:        xform.c,v;   Working file:    xform.c head:            1.2 branch: locks:           ;  strict access list: symbolic names: comment leader:  " * " total revisions: 2;    selected revisions: 2 description: Matrix transform routines, for single-precision data. ---------------------------- revision 1.2 date: 95/05/10 14:34:02;  author: rully;  state: Exp;  lines added/del: 3/3 In function ff1():  move declaration of j_coord; fix off-by-one error in traversal loop. ---------------------------- revision 1.1 date: 95/04/23 14:32:31;  author: rully;  state: Exp; As ported from 9000 engineering group sources, version 4.13. =============================================================================
sysctl -w vm.max map count=65535 
 #Adjust the min and max read-ahead for files vm.max-readahead=64 vm.min-readahead=32 #turn on memory over-commit  vm.overcommit_memory=2 #bump up the percentage of memory in use to activate bdflush vm.bdflush="40 500 0 0 500 3000 60 20 0"  
 512 32 8  
echo 511 31 7 > /proc/sys/vm/kswapd 
 511 31 7  
allocatable memory=(swap size + (RAM size * overcommit ratio)) 
 #increase the amount of RAM pagecache is allowed to use  #before we start moving it back to disk  vm.pagecache="10 40 100"  
 #lower the pagecache max to keep from eating all memory up with cache  vm.pagecache=10 25 50  #lower max-readahead to reduce the amount of unneeded IO  vm.max-readahead=16  
 #Reduce the amount of pagecache normally allowed vm.pagecache="1 10 100" #do not worry about conserving lowmem, not that many processes vm.max_map_count=128000 14 #crank up overcommit, processes can sleep as they are not interactive vm.overcommit=2  vm.overcommit_ratio=75  
$ truss -c grep asdf work.doc  syscall              seconds   calls  errors  _exit                    .00       1  read                     .01      24  open                     .00       8      4  close                    .00       5  brk                      .00      15  stat                     .00       1  fstat                    .00       4  execve                   .00       1  mmap                     .00      10  munmap                   .01       3  memcntl                  .00       2  llseek                   .00       1  open64                   .00       1                          ----     ---    ---  sys totals:              .02      76      4  usr time:                .00  elapsed:                 .05
$ truss -d who  Base time stamp:  1035385727.3460  [ Wed Oct 23 11:08:47 EDT 2002 ]   0.0000 execve(â€œ/usr/bin/whoâ€, 0xFFBEFD5C, 0xFFBEFD64)  argc = 1   0.0032 stat(â€œ/usr/bin/whoâ€, 0xFFBEFA98)                = 0   0.0037 open(â€œ/var/ld/ld.configâ€, O_RDONLY)             Err#2 ENOENT   0.0042 open(â€œ/usr/local/lib/libc.so.1â€, O_RDONLY)      Err#2 ENOENT   0.0047 open(â€œ/usr/lib/libc.so.1â€, O_RDONLY)            = 3   0.0051 fstat(3, 0xFFBEF42C)                            = 0  . . .
Dilbert> truss -D who   0.0000 execve(â€œ/usr/bin/whoâ€, 0xFFBEFD5C, 0xFFBEFD64)  argc = 1   0.0028 stat(â€œ/usr/bin/whoâ€, 0xFFBEFA98)                = 0   0.0005 open(â€œ/var/ld/ld.configâ€, O_RDONLY)             Err#2 ENOENT   0.0006 open(â€œ/usr/local/lib/libc.so.1â€, O_RDONLY)      Err#2 ENOENT   0.0005 open(â€œ/usr/lib/libc.so.1â€, O_RDONLY)            = 3   0.0004 fstat(3, 0xFFBEF42C)                            = 0
# pmap -x 1779  1779:   -ksh   Address  Kbytes     RSS    Anon  Locked Mode   Mapped File  00010000     192     192       -       - r-x--  ksh  00040000       8       8       8       - rwx--  ksh  00042000      32      32       8       - rwx--    [ heap ]  FF180000     680     664       -       - r-x--  libc.so.1  FF23A000      24      24       -       - rwx--  libc.so.1  FF240000       8       8       -       - rwx--  libc.so.1  FF280000     568     472       -       - r-x--  libnsl.so.1  FF31E000      32      32       -       - rwx--  libnsl.so.1  FF326000      32      24       -       - rwx--  libnsl.so.1  FF340000      16      16       -       - r-x--  libc_psr.so.1  FF350000      16      16       -       - r-x--  libmp.so.2  FF364000       8       8       -       - rwx--  libmp.so.2  FF380000      40      40       -       - r-x--  libsocket.so.1  FF39A000       8       8       -       - rwx--  libsocket.so.1  FF3A0000       8       8       -       - r-x--  libdl.so.1  FF3B0000       8       8       8       - rwx--    [ anon ]  FF3C0000     152     152       -       - r-x--  ld.so.1  FF3F6000       8       8       8       - rwx--  ld.so.1  FFBFE000       8       8       8       - rw---    [ stack ]  -------- ------- ------- ------- -------  total Kb    1848    1728      40       -
$ df -h  Filesystem             size   used  avail capacity  Mounted on  /dev/dsk/c0t0d0s0      4.8G   1.7G   3.0G    37%    /  /proc                    0K     0K     0K     0%    /proc  mnttab                   0K     0K     0K     0%    /etc/mnttab  fd                       0K     0K     0K     0%    /dev/fd  swap                   848M    40K   848M     1%    /var/run  swap                   849M   1.0M   848M     1%    /tmp  /dev/dsk/c0t0d0s7       13G    78K    13G     1%    /export/home
# format c0t0d0
#  Tag         Flag  Cylinders      Size      Blocks
 -  ----------  ----  -------------  --------  --------------------
 0  root        wm        0 -   812  400.15MB  (813/0/0)     819504
 1  swap        wu      813 -  1333  256.43MB  (521/0/0)     525168
 2  backup      wm        0 - 17659    8.49GB  (17660/0/0) 17801280
 3  unassigned  wm     1334 -  1354   10.34MB  (21/0/0)       21168
 4  var         wm     1355 -  8522    3.45GB  (7168/0/0)   7225344
 5  usr         wm     8523 - 14764    3.00GB  (6242/0/0)   6291936
 6  unassigned  wm    14765 - 16845    1.00GB  (2081/0/0)   2097648
 7  home        wm    16846 - 17659  400.15MB  (813/0/0)     819504
# prtvtoc /dev/rdsk/c0t0d0s2  fmthard -s - /dev/rdsk/c0t1d0s2
# metadb -a -f -c 2 c0t0d0s3 c0t1d0s3
# metadb
# metainit -f d10 1 1 c0t0d0s0
 # metainit -f d20 1 1 c0t1d0s0
 # metainit d30 -m d10
# metaroot d30
# metainit -f d11 1 1 c0t0d0s1
 # metainit -f d21 1 1 c0t1d0s1
 # metainit d31 -m d11
# metainit -f d14 1 1 c0t0d0s4
 # metainit -f d24 1 1 c0t1d0s4
 # metainit d34 -m d14
# metainit -f d15 1 1 c0t0d0s5
 # metainit -f d25 1 1 c0t1d0s5
 # metainit d35 -m d15
# metainit -f d16 1 1 c0t0d0s6
 # metainit -f d26 1 1 c0t1d0s6
 # metainit d36 -m d16
# metainit -f d17 1 1 c0t0d0s7
 # metainit -f d27 1 1 c0t1d0s7
 # metainit d37 -m d17
fd                 -                   /dev/fd  fd     -  no   -
 /proc              -                   /proc    proc   -  no   -
 /dev/dsk/c0t0d0s1  -                   -        swap   -  no   -
 /dev/md/dsk/d30    /dev/md/rdsk/d30    /        ufs    1  no   logging
 /dev/dsk/c0t0d0s5  /dev/rdsk/c0t0d0s5  /usr     ufs    1  no   ro,logging
 /dev/dsk/c0t0d0s4  /dev/rdsk/c0t0d0s4  /var     ufs    1  no   nosuid,logging
 /dev/dsk/c0t0d0s7  /dev/rdsk/c0t0d0s7  /home    ufs    2  yes  nosuid,logging
 /dev/dsk/c0t0d0s6  /dev/rdsk/c0t0d0s6  /opt     ufs    2  yes  nosuid,logging
 swap               -                   /tmp     tmpfs  -  yes  -
fd                 -                   /dev/fd  fd     -  no   -
 /proc              -                   /proc    proc   -  no   -
 /dev/md/dsk/d31    -                   -        swap   -  no   -
 /dev/md/dsk/d30    /dev/md/rdsk/d30    /        ufs    1  no   logging
 /dev/md/dsk/d35    /dev/md/rdsk/d35    /usr     ufs    1  no   ro,logging
 /dev/md/dsk/d34    /dev/md/rdsk/d34    /var     ufs    1  no   nosuid,logging
 /dev/md/dsk/d37    /dev/md/rdsk/d37    /home    ufs    2  yes  nosuid,logging
 /dev/md/dsk/d36    /dev/md/rdsk/d36    /opt     ufs    2  yes  nosuid,logging
 swap               -                   /tmp     tmpfs  -  yes  -
# lockfs -fa && init 6
# metattach d30 d20
 # metattach d31 d21
 # metattach d34 d24
 # metattach d35 d25
 # metattach d36 d26
 # metattach d37 d27
# dumpadm -d `swap -l  tail -1  awk '{print $1}'
# installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c0t1d0s0
# ls -l /dev/dsk/c0t1d0s0
 ... /dev/dsk/c0t1d0s0 -> ../../devices/pci@1f,4000/scsi@3/sd@1,0:a
# eeprom "nvramrc=devalias mirror /pci@1f,4000/scsi@3/disk@1,0"
 # eeprom "use-nvramrc?=true"
# eeprom "boot-device=disk mirror cdrom net"
ok nvalias mirror /pci@1f,4000/scsi@3/disk@1,0
 ok use-nvramrc?=true
 ok boot-device=disk mirror cdrom net
/sbin/init

/sbin/init
/etc/rcS.d/S30rootusr.sh
/etc/rcS.d/S30rootusr.sh
/usr
/etc/rcS.d/S30rootusr.sh
/etc/rcS/S30rootusr.sh
/etc/rc2.d/S69inet
/etc/rc2.d/S71rpc
/etc/rc2.d/S71
/etc/rc2.d/S72inetsvc
/etc
/etc/nodename
/etc/hostname.interface
/etc/hostname.interface
/etc/inet/hosts
/usr
/etc/defaultdomain
deserts.worldwide.com
deserts.worldwide.com
/etc/defaultdomain
/etc/defaultrouter
/etc/inet/hosts
/etc/inet/netmasks
/tftpboot

# mkdir /tftpboot

# ln -s /tftpboot/. /tftpboot/tftpboot
/etc/inetd.conf

tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd -s         /tftpboot
/tftpboot
/etc/nodename
/etc/nodename
/etc/hostname.interface
/etc/hostname.interface
/etc/inet/hosts
/etc/defaultdomain file
/etc/defaultdomain
/etc/nsswitch.conf
/etc/defaultrouter
/etc/defaultrouter
/etc/inet/hosts
/etc/defaultrouter
/etc/defaultrouter

nsswitch.conf
/etc/nsswitch.conf
/etc/nsswitch.conf
# /etc/nsswitch.files: # # An example file that could be copied over to /etc/nsswitch.conf; # it does not use any naming service. # # "hosts:" and "services:" in this file are used only if the # /etc/netconfig file contains "switch.so" as a # nametoaddr library for "inet" transports. passwd: files group: files hosts: files networks: files protocols: files rpc: files ethers: files netmasks: files bootparams: files publickey: files # At present there isn't a 'files' backend for netgroup; the # system will figure it out pretty quickly, # and won't use netgroups at all. netgroup: files automount: files aliases: files services: files sendmailvars: files

database name-service-to-search
/etc
/etc/inet
nsswitch.conf
/etc
nsswitch.conf
## /etc/nsswitch.conf:# . . passwd: files nis group: file nis # consult /etc "files" only if nis is down. hosts: nis [NOTFOUND=return] files networks: nis [NOTFOUND=return] files protocols: nis [NOTFOUND=return] files rpc: nis [NOTFOUND=return] files ethers: files [NOTFOUND=return] nis netmasks: nis [NOTFOUND=return] files bootparams: files [NOTFOUND=return] nis publickey: nis netgroup: nis automount: files nis aliases: files nis # for efficient getservbyname() avoid nis services: files nis sendmailvars: files

bootparams
/etc/bootparams
    machine-name file-key-server-name:pathname
myclient root=myserver : /nfsroot/myclient \ swap=myserver : /nfsswap//myclient \ dump=myserver : /nfsdump/myclient
dump=:
    * root=server:/path dump=:

ethers
/etc/ethers
 Ethernet-address hostname #comment
Ethernet-address is the    Ethernet address of the host.
hostname is the official name of the    host.
#comment is any kind of note you want to append to an entry in the    file.
8:0:20:1:40:16 fayoum 8:0:20:1:40:15 nubian 8:0:20:1:40:7 sahara # This is a comment 8:0:20:1:40:14 tenere

networks database
  network-name network-number nickname(s) # comment   network-name is the official name for the network.   network-number is the number assigned by the InterNIC.   nickname is any other name by which the network is known.   #comment is any kind of note you want to append to an entry in the file.
/etc/networks
#ident "@(#)networks 1.4 92/07/14 SMI" /* SVr4.0 1.1 */ # # The networks file associates Internet Protocol (IP) network numbers with network names. The format of this file is: # # network-name network-number nicnames . . . # The loopback network is used only for intra-machine communication #loopback 127 # Internet networks # arpanet 10 arpa # Historical ucb-ether 46 ucbether # # local networks eng 193.9.0 #engineering acc 193.9.1 #accounting prog 193.9.2 #programming

protocols
/etc/inet/protocols
# # Internet (IP) protocols # ip 0 IP # internet protocol, pseudo protocol number icmp 1 ICMP # internet control message protocol tcp 6 TCP # transmission control protocol udp 17 UDP # user datagram protocol

services
/etc/inet/services
# # Network services # echo 7/udp echo 7/tcp discard 9/udp sink null discard 11/tcp daytime 13/udp daytime 13/tcp netstat 15/tcp ftp-data 20/tcp ftp 21/tcp telnet 23/tcp time 37/tcp timeserver time 37/udp timeserver name 42/udp nameserver whois 43/tcp nickname

/etc/resolv.conf
/etc/resolv.conf
/etc/resolv.conf
nameserver 63.67.120.18 nameserver 63.67.120.23

/etc/hostname.interface
eri0
alexprod
/etc/hostname.
/etc/hostname.eri0
alexprod
alexprod

/etc/nodename
alexprod
/etc/nodename
alexprod
alexprod

/etc/defaultdomain
iDevelopment
.info
/etc/defaultdomain
iDevelopment.info
idevelopment.info

/etc/defaultrouter
/etc/defaultrouter
192.168.1.1

/etc/hosts
/etc/inet/hosts
/etc/hosts
/etc/inet/hosts
# # Internet host table # 127.0.0.1       localhost 192.168.1.102    alexprod alexprod.idevelopment.info    loghost

/etc/inet/netmasks
# # The netmasks file associates Internet Protocol (IP) address # masks with IP network numbers. # #       network-number  netmask # # The term network-number refers to a number obtained from the Internet Network # Information Center.  Currently this number is restricted to being a class # A, B, or C network number.  In the future we should be able to support # arbitrary network numbers per the Classless Internet Domain Routing # guidelines. # # Both the network-number and the netmasks are specified in # "decimal dot" notation, e.g: # #               128.32.0.0 255.255.255.0 # 192.168.1.0      255.255.255.0

/etc/nsswitch.conf
/etc/nsswitch.conf
/etc/nsswitch.conf
/etc/nsswitch.conf

nsswitch.files

nsswitch.nis

nsswitch.dns

nsswitch.ldap

nsswitch.nisplus
/etc/nsswitch.conf
# # /etc/nsswitch.files: # # An example file that could be copied over to /etc/nsswitch.conf; it # does not use any naming service. # # "hosts:" and "services:" in this file are used only if the # /etc/netconfig file has a "-" for nametoaddr_libs of "inet" transports.  passwd:     files group:      files hosts:      files ipnodes:    files networks:   files protocols:  files rpc:        files ethers:     files netmasks:   files bootparams: files publickey:  files # At present there isn't a 'files' backend for netgroup;  the system will #   figure it out pretty quickly, and won't use netgroups at all. netgroup:   files automount:  files aliases:    files services:   files sendmailvars:   files printers:       user files  auth_attr:  files prof_attr:  files project:    files
/etc/nsswitch.conf
# # /etc/nsswitch.dns: # # An example file that could be copied over to /etc/nsswitch.conf; it uses # DNS for hosts lookups, otherwise it does not use any other naming service. # # "hosts:" and "services:" in this file are used only if the # /etc/netconfig file has a "-" for nametoaddr_libs of "inet" transports.  passwd:     files group:      files  # You must also set up the /etc/resolv.conf file for DNS name # server lookup.  See resolv.conf(4). hosts:      files dns ipnodes:    files # Uncomment the following line and comment out the above to resolve # both IPv4 and IPv6 addresses from the ipnodes databases. Note that # IPv4 addresses are searched in all of the ipnodes databases before # searching the hosts databases. Before turning this option on, consult # the Network Administration Guide for more details on using IPv6. #ipnodes:   files dns  networks:   files protocols:  files rpc:        files ethers:     files netmasks:   files bootparams: files publickey:  files # At present there isn't a 'files' backend for netgroup;  the system will #   figure it out pretty quickly, and won't use netgroups at all. netgroup:   files automount:  files aliases:    files services:   files sendmailvars:   files printers:       user files  auth_attr:  files prof_attr:  files project:    files
/etc/nsswitch.conf
# /etc/nsswitch.nis: # # An example file that could be copied over to /etc/nsswitch.conf; it # uses NIS (YP) in conjunction with files. # # "hosts:" and "services:" in this file are used only if the # /etc/netconfig file has a "-" for nametoaddr_libs of "inet" transports.  # the following two lines obviate the "+" entry in /etc/passwd and /etc/group. passwd:     files nis group:      files nis  # consult /etc "files" only if nis is down. hosts:      files dns nis ipnodes:    files # Uncomment the following line and comment out the above to resolve # both IPv4 and IPv6 addresses from the ipnodes databases. Note that # IPv4 addresses are searched in all of the ipnodes databases before # searching the hosts databases. Before turning this option on, consult # the Network Administration Guide for more details on using IPv6. #ipnodes:    nis [NOTFOUND=return] files  networks:   nis [NOTFOUND=return] files protocols:  nis [NOTFOUND=return] files rpc:        nis [NOTFOUND=return] files ethers:     nis [NOTFOUND=return] files netmasks:   nis [NOTFOUND=return] files bootparams: nis [NOTFOUND=return] files publickey:  nis [NOTFOUND=return] files  netgroup:   nis  automount:  files nis aliases:    files nis  # for efficient getservbyname() avoid nis services:   files nis sendmailvars:   files printers:       user files nis  auth_attr:  files nis prof_attr:  files nis project:    files nis
/dev/dsk
/dev/rdsk
/devices
/dev/dsk
/dev/rdsk
/dev/cfg
/devices
/etc/path_to_inst
boot    -p
devfsadm
devfsadm
/usr/sbin/devfsadm
/dev
/devices
devfsadm
drvconfig(1M)
disks(1M)
tapes(1M)
ports(1M)
audlinks(1M)
evlinks(1M)
devfsadm
  # devfsadm -C
devfsadm
/etc/path_to_inst
/dev/dsk/cX*
/dev/rdsk/cX*
X
/dev/cfg/cX
/dev/cfg/2
/dev/cfg/3
/devices/*
/dev/sdXX*
ok boot -srv
c0t2d0s7
/dev/dsk/c0t2d0s7
/dev/dsk
mount
/dev/rdsk
fsck
newfs
/etc/vfstab
/dev/dsk/c0t2d0s7 /dev/rdsk/c0t2d0s7 /opt ufs 3 yes - 
mount
fsck
newfs
/etc/vfstab
c0t2d0s7
c0t2d0s7

c0

t2

d0

s7
format
/etc/release
# cat /etc/release            Solaris 8 2/02 s28s_u7wos_08a SPARC Copyright 2002 Sun Microsystems, Inc.  All Rights Reserved.              Assembled 18 December 2001
shutdown
init 0
ok
ok
init 0
probe-scsi-all
ok probe-scsi-all /pci@1f,2000/scsi@2 Target 8 Unit 0 Disk SEAGATE ST34371W SUN4.2G8254 /pci@1f,2000/scsi@2,1 Target 1 Unit 0 Disk SEAGATE ST34371W SUN4.2G8254
ok boot -r
# su
# /opt/SUNWvts/bin/sunvts
$ su - $ cd /usr/lib/nfs $ ./mountd $ ./nfsd

mountd:

nfsd:
/software
# share /software
# share -               /software   rw   ""
# mount -F nfs alex:/software /mnt/software
# umount /mnt/software
pkgchk
# /usr/sbin/pkgchk -l -p /absolute/path/todir
# /usr/sbin/pkgchk -l -p /usr/bin/pgrep Pathname: /usr/bin/pgrep Type: regular file Expected mode: 0555 Expected owner: root Expected group: bin Expected file size (bytes): 14688 Expected sum(1) of contents: 63968 Expected last modification: Mar 16 05:53:45 AM 2000 Referenced by the following packages:         SUNWcsu Current status: installed
# grep /usr/bin/pgrep /var/sadm/install/contents /usr/bin/pgrep f none 0555 root bin 14688 63968 953204025 SUNWcsu
# /usr/platform/`uname -i`/sbin/prtdiag -v  System Configuration: Sun Microsystems  sun4u Sun Blade 150 (UltraSPARC-IIe 650MHz) System clock frequency: 93 MHZ Memory size: 1.75GB  ==================================== CPUs ====================================                E$          CPU     CPU       Temperature CPU  Freq      Size        Impl.   Mask     Die    Ambient ---  --------  ----------  ------  ----  --------  --------  0    650 MHz  512KB       US-IIe   3.3     56 C     29 C  ================================= IO Devices =================================      Bus   Freq Brd  Type  MHz   Slot        Name                              Model ---  ----  ----  ----------  --------------------------------  ----------------------  0   pci    33            7  isa/dma-isadma (dma)  0   pci    33            7  isa/serial-su16550 (serial)  0   pci    33            7  isa/serial-su16550 (serial)  0   pci    33            8  sound-pci10b9,5451.10b9.5451.1 (+  0   pci    33           12  network-pci108e,1101.1 (network)  SUNW,pci-eri  0   pci    33           12  firewire-pci108e,1102.1001 (fire+  0   pci    33           13  ide-pci10b9,5229.c3 (ide)  0   pci    33           19  SUNW,m64B (display)               ATY,RageXL  ============================ Memory Configuration ============================ Segment Table: ----------------------------------------------------------------------- Base Address       Size       Interleave Factor  Contains ----------------------------------------------------------------------- 0x0                256MB             1           Label DIMM0 0x40000000         512MB             1           Label DIMM1 0x80000000         512MB             1           Label DIMM2 0xc0000000         512MB             1           Label DIMM3  =============================== usb Devices ===============================  Name          Port# ------------  ----- device          4  =============================== device#4 Devices ===============================  Name          Port# ------------  ----- keyboard      mouse ============================ Environmental Status ============================ Fan Speeds: ---------------------------- Fan Device            Speed ---------------------------- system                 100%  ================================ HW Revisions ================================ ASIC Revisions: --------------- ebus: Rev 1  System PROM revisions: ---------------------- OBP 4.6.5 2002/06/03 16:49 POST 2.0.1 2001/08/23 17:13
# /usr/sbin/prtconf  System Configuration:  Sun Microsystems  sun4u Memory size: 1792 Megabytes System Peripherals (Software Nodes):  SUNW,Sun-Blade-100     packages (driver not attached)         SUNW,builtin-drivers (driver not attached)         deblocker (driver not attached)         disk-label (driver not attached)         terminal-emulator (driver not attached)         obp-tftp (driver not attached)         dropins (driver not attached)         kbd-translator (driver not attached)         ufs-file-system (driver not attached)     chosen (driver not attached)     openprom (driver not attached)         client-services (driver not attached)     options, instance #0     aliases (driver not attached)     memory (driver not attached)     virtual-memory (driver not attached)     pci, instance #0         ebus, instance #1             flashprom (driver not attached)             eeprom (driver not attached)             idprom (driver not attached)         isa, instance #0             dma, instance #0                 floppy, instance #0                 parallel (driver not attached)             power, instance #0             serial, instance #0             serial, instance #1         network, instance #0         firewire, instance #0         usb (driver not attached)         pmu, instance #0             i2c, instance #0                 temperature, instance #0                 card-reader (driver not attached)                 dimm (driver not attached)                 dimm (driver not attached)                                 dimm (driver not attached)                 dimm (driver not attached)             ppm, instance #0             beep, instance #0             fan-control, instance #0         sound (driver not attached)         ide, instance #0             disk (driver not attached)             cdrom (driver not attached)             dad, instance #0             dad, instance #1             sd, instance #0         pci (driver not attached)         SUNW,m64B, instance #0     SUNW,UltraSPARC-IIe, instance #0     pseudo, instance #0
  # pkgadd -d samba-2.0.5-sol7-sparc-local
  # pkginfo | grep -i samba   application SMCsamba       samba
  # pkgrm SMCsamba
dtpower
dtpower
# /usr/openwin/bin/dtpower
/etc/power.conf
/etc/power.conf
# # Copyright (c) 1996 - 2001 by Sun Microsystems, Inc. # All rights reserved. # #pragma ident   "@(#)power.conf 1.14    99/10/18 SMI" # # Power Management Configuration File #  # Statefile     Path statefile               /usr/.CPR   # Auto-Shutdown Idle(min)       Start/Finish(hh:mm)     Behavior autoshutdown    30              9:00 9:00       noshutdown  device-dependency-property removable-media /dev/fb autopm          disable  system-threshold                always-on
# /usr/sbin/pmconfig
/etc/power.conf
/etc/power.conf
pmconfig
# If CONSOLE is set, root can only login on that device. # Comment this line out to allow remote login by root. # # CONSOLE=/dev/console
/etc/ftpusers
/etc/ftpaccess
ftp*
/etc/ftpd
eeprom
/usr/sbin/eeprom
eeprom
eeprom
eeprom
eeprom
eeprom
eeprom
eeprom
# eeprom auto-boot? auto-boot?=true # eeprom test-args: data not available. diag-passes=1 pci-probe-list=7,c,3,8,d,13,5 local-mac-address?=false fcode-debug?=false ttyb-rts-dtr-off=false ttyb-ignore-cd=true ttya-rts-dtr-off=false ttya-ignore-cd=true silent-mode?=false scsi-initiator-id=7 oem-logo: data not available. oem-logo?=false oem-banner: data not available. oem-banner?=false ansi-terminal?=true screen-#columns=80 screen-#rows=34 ttyb-mode=9600,8,n,1,- ttya-mode=9600,8,n,1,- output-device=screen input-device=keyboard load-base=16384 auto-boot?=true boot-command=boot diag-file: data not available. diag-device=disk net boot-file: data not available. boot-device=disk net use-nvramrc?=false nvramrc: data not available. security-mode=none security-password: data not available. security-#badlogins=0 mfg-mode=off diag-level=max diag-switch?=false error-reset-recovery=boot
ok
# eeprom "auto-boot?"=false
  % iostat -xn ...                               extended device statistics   r/s  w/s   kr/s   kw/s wait actv wsvc_t asvc_t   %w   %b device  21.9 63.5 1159.1 2662.9  0.0  2.7    0.0   31.8   0    93 c3t15d0   
  % se siostat.se 10 03:42:50  ------throughput------ -----wait queue----- ----active queue---- disk      r/s  w/s   Kr/s   Kw/s qlen res_t svc_t  %ut qlen res_t svc_t  %ut c0t2d0s0  0.0  0.2    0.0    1.2 0.00  0.02  0.02    0 0.00 22.87 22.87   0 03:43:00  ------throughput------ -----wait queue----- ----active queue---- disk      r/s  w/s   Kr/s   Kw/s qlen res_t svc_t  %ut qlen res_t svc_t  %ut c0t2d0s0  0.0  3.2    0.0   23.1 0.00  0.01  0.01    0 0.72 225.45 16.20   5   
             total       used       free     shared    buffers     cached  Mem:           503        451         52          0         14        293  -/+ buffers/cache:        143        360  Swap:         1027          0       1027 
Processor Type and Features ----> High Memory Support ---->  (*) 4GB 
sysctl -w vm.swappiness=30  echo 30 >/proc/sys/vm/swappiness 
# Control how much the kernel should favor swapping out applications (0-100) vm.swappiness = 30 
ck-sources
INFODOC ID: 13335  SYNOPSIS: NETWORK SECURITY PSD/FAQ DETAIL DESCRIPTION:  Product Support Document (PSD) for Network Security  Revision 1.1 Date: April 18, 1996  1.0: About Network Security   1.1: Network Security Definitions 2.0: Network Security Debugging 3.0: Common How Tos   3.1: How to Prevent Remote Root Logins Under SunOS   3.2: How to Prevent Remote Root Logins Under Solaris   3.3: How to Turn Off Specific Network Services   3.4: How to Insure the Security of NFS Partitions   3.5: How to Insure the Security of NIS Maps   3.6: How to Insure the Security of NIS+ Maps   3.7: How to Keep Up to Date with the Latest Security Problems   3.8: How to Take Additional Steps to Secure Your Site 4.0: Frequently Asked Questions 5.0: Network Security Patches   5.1: Miscellaneous Networking Patches   5.2: DNS Patches   5.3: FTP Patches   5.4: Inetd Patches   5.5: NFS Patches   5.6: NIS Patches   5.7: nscd Patches   5.8: Sendmail Patches 6.0: Known Bugs & RFEs 7.0: References 8.0: Supportability 9.0: Additional Support  1.0 About Network Security   1.0: About Network Security  ===========================  As the internet gets continually bigger, the question of network security becomes an ever larger one. What follows are some tips and guidelines that you can use to get yourself started with network security. If network security is an extremely critical issue at your site, consider working with the Consulting services described in Section 9.0, because this document can really only touch the surface of a very important subject.  This PSD tries to impart the following information: first, what can be done on a brand-new Sun to setup basic network security  second, what public-domain or SunSoft programs can be used to improve security even further. It does not discuss security issues unrelated to the network (e.g. setuid programs, file permissions, restricted shells, etc), but you should consider these matters when you are working to secure your system.   1.1: Network Security Definitions  ---------------------------------  A lot of varied ground is covered in this PSD.  The following terms are important to some parts of it:  FIREWALL: A machine positioned in between your internal network and external networks (usually the internet). The most strict firewalls prevent any packets from being transmitted from the internal to external networks, depending on PROXY SERVERS for needed functionality. Less strict firewalls only prevent certain types of insecure packets (i.e., X11 packets) from being passed.  PROXY SERVER: A daemon run on a firewall, which acts as a sort of go-between, accepting packets from the internal network and connecting them up to services on the external network, as appropriate (or vice-versa). Proxy servers are useful because they allow connections to go beyond a firewall, but still hide all information on the internal network from external users.  FILTERING ROUTER: Really, a type of firewall. Filtering routers can be programmed to block certain types of packets (X11, sendmail, telnet, etc).   2.0: Network Security Debugging  ===============================  The best way to "debug" network security is to read this Tip Sheet and take a look at the programs noted in section 3.8. In particular: security scanners can point out security holes in your current setup, while firewalls and TCP/IP wrappers can be set up to provide a high level of logging, giving lots of information about security-related network activity.  3.0 Common How Tos   3.1: How to Prevent Remote Root Logins Under SunOS  ---------------------------------------------------  Remote root login permissions are controlled by the /etc/ttytab file under SunOS. To change remote root login permissions, you must modify every single 'network' line in the /etc/ttytab files.  Root access over the network is denied if all of the network ttys are labelled unsecure:    ttyp0   none                            network         off unsecure  After making changes to the ttytab, you must HUP process 1:    # kill -HUP 1  Alternatively, you can reboot the machine.   3.2: How to Prevent Remote Root Logins Under Solaris  ----------------------------------------------------  In the file /etc/default/login, there is a CONSOLE line.  If there is no comment in front of the CONSOLE line, root can only login from the console:    CONSOLE=/dev/console  Changes to this file will take effect at once.   3.3: How to Turn Off Specific Network Services  ----------------------------------------------  Network programs can be started from a variety of places. You must know how they are started in order to turn them off.  The majority of network services that you will wish to disable are enabled in the /etc/inetd.conf file. To disable one of these services, simply comment out the appropriate line. For example, to disallow logins you would want to disable the following three services:    #telnet  stream  tcp     nowait  root    /usr/sbin/in.telnetd    in.telnetd   #shell   stream  tcp     nowait  root    /usr/sbin/in.rshd       in.rshd   #login   stream  tcp     nowait  root    /usr/sbin/in.rlogind    in.rlogind  ftpd, tftpd, fingerd and many other internet services can all be disabled in a similar manner. Afterwards, you must restart the inetd:    # kill -HUP inetd-pid  Most other network services (sendmail, rpc.nisd, etc) are initiated from the rc files. If a network service does not appear in the inetd, you should search through your rc files, find where it is started, and then comment out the daemon so that it does not start on bootup. You'll of course have to kill the currently running daemon to disable the service immediately.   3.4: How to Insure the Security of NFS Partitions  -------------------------------------------------  When you are exporting NFS partitions, if you don't have a firewall or filtering router that prevents NFS packets from leaving your domain, you should make sure to restrict access rights to that partition. This is done by restricting the rw or ro option to a specific machine, a list of machines or a netgroup. Examples of using the rw and ro options in this way follow:    rw=machine1   rw=machine1,machine2,machine3   rw=netgroup   ro=machine1   ro=machine1,machine2,machine3   ro=netgroup  These options should be incorporated into your export file in a way appropriate to your network. For example, under, SunOS, you might use the following:    %% cat /etc/exportfs   /export       -ro=machine1  Under Solaris, you might use the following:    %% cat /etc/dfs/dfstab   share -F nfs -o ro=netgroup /export  Note that it is most convenient to set up a netgroup that contains a listing of all of your machines and then export all of your NFS partitions to that netgroup. SunService has a NIS PSD that gives good information on how to set up a netgroup.   3.5: How to Insure the Security of NIS Maps  -------------------------------------------  By default, NIS is not particularly secure. Anyone can grab a copy of NIS maps by simply figuring out the name of your NIS domain. Thus, the first step in securing NIS to use a nonintuitive name for your defaultdomain. Something that is not a derivation of your domain name or machine name is best.  Newer versions of NIS allow you to further secure things via the securenets file. If you are using SunOS 4.1.3_U1 or lower or NSkit 1.0 or lower, you need to apply the appropriate patch before the securenets file can be used. SunOS 4.1.4 and newer versions of NSkit already have this available by default.  The contents of the /var/yp/securenets file should be a number of lines that each read:    netmask address  For example, if you only wanted the machines 150.101.16.28 and 150.101.16.29 to be able to retrieve your NIS maps, you could enter the two lines:    255.255.255.255 150.101.16.28   255.255.255.255 150.101.16.29  If you wanted everyone on the network 150.101.16.0 to be able to retrieve your maps, you could enter the line:    255.255.255.0 150.101.16.0   3.6: How to Insure the Security of NIS+ Maps  --------------------------------------------  NIS+ provides much better security than NIS and is highly suggested if you are worried about the security of your network. You can control who can access your maps with the NIS+ access rights. Type nisdefaults to examine the default values for your NIS+ domain:    %% nisdefaults -r   ----rmcdr---r---  Type niscat -o to determine the rights on an individual table:    %% niscat -o passwd   ...   Access Rights : ----rmcdr---r---  Remember that these access rights are laid out in the format: nobody, owner, group, world, and that each of these four user groups has four access rights: read, modify, create, destroy. In the above examples, owner has all rights, while group and world have only read rights. Nobody has no rights.  The above setup is secure under NIS+, since only people who are authenticated into your domain are able to look at your tables. You should only worry if you have extended rights to the nobody group. This might be required if you need to extend rights to NIS clients or to unauthenticated clients, but you should be aware that it reduces your security.  If you need to change your access rights, you should use the nischmod command. NIS+ is very powerful and you can give rights to entire objects or individual table entries. Consult the nischmod for information on how to do this.   3.7: How to Keep Up to Date with the Latest Security Problems  -------------------------------------------------------------  Though this document explains how to make your network services more secure, there are constantly new issues cropping up. If you want to make sure that your network remains secure in the future, you need to keep up with these new problems. Fortunately, there is an excellent third-party mailings list on the net that tells of network security problems as they become known.  The CERT (Computer Emergency Response Team) Coordination Center publishes CERT advisories that tell of the newest network security problems for all OSes. You can subscribe to it by mailing:          cert-advisory-request@cert.org   3.8: How to Take Additional Steps to Secure Your Site  -----------------------------------------------------  Sections 3.1 through 3.6 of this document describe how to make your system as secure as possible, using the tools that came with it. Following those basic guidelines should provide more than enough security for most sites.  However, there are some cases where you might want to implement additional levels of security, even preventing certain services from arriving at your site, in the name of making your network security even more ironclad. Addressed here are certain public-domain or Sun products that are especially helpful. There are also many third-party security programs available from other vendors.  Firewalls ---------  Firewalls are the ultimate in security, because they can totally isolate you from most of the network. Sun sells a Firewall product named Firewall-1. Consult with your local Sun Sales office for info on how to purchase Firewall-1.  A separate PSD exists on the FW-1 Product.  Security Scanners -----------------  Certain Security Scanners have been written that check for a number of common security problems. In general, if you've secured everything as noted in 3.1-3.6 and applied the patches described in section 5.0, you won't have any problems. However, you mightcan still wish to try these out.  Cops checks for all kinds of common problems (including many non-network related ones) on a single machine:    ftp://ftp.cert.org/pub/tools/cops  ISS (the Internet Security Scanner) can probe for common security problems on an entire network of machines:    ftp://ftp.cert.org/pub/tools/iss  TCP/IP Wrappers ---------------  These public domain wrappers can be used to log the use of certain TCP/IP programs (i.e., telnetd) and also to prevent access from certain sites or networks. They are available from:    ftp://ftp.cert.org/pub/tools/tcp_wrappers  Other Programs --------------  A number of other public domain network security programs are available from:    ftp://ftp.cert.org/pub/tools  You can also be interested in joining the CERT Tools mailing list, that announces the release of new security tools. You can request membership on the CERT Tools mailing list by dropping a line to:    cert-tools-request@cert.org   4.0: Frequently Asked Questions  ===============================  Q: Why should I worry about security?  A: There are crackers out on the net and in time just about every single site gets hit by them. Fortunately, if your site has a minimum level of security (i.e., no gaping security holes), the crackers will move on. Although the advice in this document will not necessarily make your site impregnable, it will provide sufficient security to keep 99.9%% of potential attackers out.  Q1: What issues should I consider when setting up security at my site? Q2: How for should I go with implementing security policies on my network?  A: When considering security at your site, you need to balance level of security with ease of use. Although a lot of basic security can be accomplished with no inconvenience to your users, when you start working with firewalls, TCP wrappers and filtering routers, you will be taking some functionality away from your users. Based on the visibility of your site and the confidentiality of its data, you must determine how much is enough and how much is too much. This varies from site to site, but a Security Consultant might be able to give you a little more direction in making this decision.  Q: What services might I want to disable?  TFTP should absolutely be disabled if you don't have diskless clients taking advantage of it.  Many sites will also disable finger, so that external users can't figure out the user names of your internal users.  Everything else pretty much depends on the needs of your site. Do people need to login from outside your network? FTP? If services are not being used, disabling them can prevent later unauthorized use.  5.0 Network Security Patches   5.0: Network Security Patches  =============================  The followings patches specifically fix some manner of security problem in the listed network program. In no way is this a complete list of network patches, but simply a list of those that can have impact upon site security.   5.1: Miscellaneous Networking Patches  -------------------------------------  100567-04 SunOS 4.1,4.1.1, 4.1.2, 4.1.3: mfree and icmp redirect security 101587-01 SunOS 4.1.3_U1: security patch for mfree and icmp redirect    Makes a machine resistant to ICMP spoofing.   5.2: DNS Patches  ----------------  102167-03 SunOS 5.3: dns fix 102165-03 SunOS 5.4: nss_dns.so.1 fixes    Make DNS more resistant to spoofing. These do not upgrade in.named   to Bind 4.9.3 and thus some security holes remain. These should be   corrected in the near future.   5.3: FTP Patches  ----------------  101640-03 SunOS 4.1.3: in.ftpd logs password info when -d option is used.    Fixes an error that caused in.ftpd to log passwords when run with   the -d option.   5.4: Inetd Patches  ------------------  101786-02 SunOS 5.3: inetd fixes 102922-03 SunOS 5.4: inetd fixes 102923-03 SunOS 5.4_x86: inetd fixes    Mostly related to performance problems, but also fixes a minor   security hole.   5.5: NFS Patches  ----------------  102177-04 SunOS 4.1.3_U1: NFS Jumbo Patch 102394-02 SunOS 4.1.4: NFS Jumbo Patch    Fix various NFS security holes.   5.6: NIS Patches  ----------------  100482-07 SunOS 4.1 4.1.1 4.1.2 4.1.3: ypserv and ypxfrd Jumbo Patch 101435-02 SunOS 4.1.3_U1: ypserv and ypxfrd fix 101363-09 NSkit 1.0: Jumbo Patch    These patches are required to allow the usage of the securenets file   in these older releases of NIS.  102034-01 SunOS 5.3: portmapper security hole    Fixes for NIS-related portmapper security holes.  102707-02 SunOS 5.3: jumbo patch for NIS commands 102704-02 SunOS 5.4: jumbo patch for NIS commands 102705-02 SunOS 5.4_x86: jumbo patch for NIS commands    These patches fix ypxfr related NIS problems that became apparent   with NSKit 1.2.  103053-01 SunOS 5.4, 5.3: Jumbo patch for NSKIT v1.2    A patch specifically for NSKit 1.2, fixing a few more security   problems.   5.7: nscd Patches  -----------------  103279-02 SunOS 5.5: nscd breaks password shadowing with NIS+    Keeps nscd from violating NIS+ shadow passwd security.   5.8: Sendmail Patches  ---------------------  100377-22 SunOS 4.1.3: sendmail jumbo patch 101665-07 SunOS 4.1.3_U1: sendmail jumbo patch 102423-04 Sunos 4.1.4: Sendmail jumbo patch    Fix a variety of older sendmail problems. These patches do not bring   the SunOS sendmail up to version 8.6.10+ and so certain new   sendmail problems are not yet addressed. They will be in the near   future.  101739-12 SunOS 5.3: sendmail jumbo patch - security 102066-11 SunOS 5.4: sendmail jumbo patch - security 102064-10 SunOS 5.4_x86: sendmail jumbo patch - security    These patches bring Solaris sendmail up to version 8.6.10+, fixing   all known sendmail security holes.  6.0 Known Bugs And  RFEs   6.1: Bugs  ---------  1238679   DNS spoofing is possible per Cern ca-96.02    This documents the existing DNS security hole noted above, which is   present in releases of BIND prior to 4.9.3. An upgrade of the SunOS   and Solaris BINDs to 4.9.3 is currently in process and should be   accomplished within the next few months.  1237810   4.1.x Unix sendmail vulnerability according to CIAC Bulletin G-    This documents the fact that 4.1.X sendmail has some security holes   because it has not been upgraded to 8.6.10+. An upgrade of the SunOS   sendmail to 8.6.10+ is currently in process and should be   accomplished within the next few months.  7.0 References   7.1: Important Man Pages  ------------------------  No specific man pages refer to internet security.   7.2: Sunsolve Documents  -----------------------  The following sunsolve documents provide some information not included here.  7.2.1: Infodocs ---------------  2105      convert existing NIS(yp) network to secure C2 domain 12793     What are the security ramifications of running TFTP?  7.2.2: SRDBs ------------  6010      C2 security and Solaris 2.x   7.3: Sun Educational Services  -----------------------------  There are no classes specifically on network security.   7.4: Solaris Documentation  --------------------------  There is no Solaris documentation specifically on network security.   7.5: Third Party Documentation  ------------------------------  The following books are not necessarily restricted to the network aspect of security, but do provide some information on it.  _Computer Security Basics_, published by O'Reilly & Associates  _Practical UNIX Security_, published by O'Reilly & Associates   7.6: RFCs  ---------  1244    the Site Security Handbook 1281    Guidelines for the Secure Operation of the Internet   8.0: Supportability  ===================  SunService is not responsible for helping design security policies at your site. It is hoped that this document will help you to maintain robust network security at your site on your.  We can help resolve problems where a Sun program has a security problem with it, but in such cases the contact must be a system administrator with a good understanding of the security issues.   9.0: Additional Support  =======================  For additional help determining security policies at your site, please contact your local SunService office for possible consulting offerings. Sun's Customer Relations organization can put you in touch with your local SunIntegration or Sales office. You can reach Customer Relations at 800-821-4643.   PRODUCT AREA: Gen. Network PRODUCT: Security SUNOS RELEASE: any HARDWARE: n/a  
   INFODOC ID: 11987  SYNOPSIS: NFS PSD/FAQ DETAIL DESCRIPTION:  1.0 About NFS  SunService Tip Sheet for Sun NFS  Revision: 2.9 Date: June 25, 1996  Mail to: brian.hackley@east.sun.com Mail to: gwhite@east.sun.com  Table of Contents  1.0: About NFS 2.0: Debugging NFS   2.1: share and exportfs   2.2: showmount   2.3: nfsstat   2.4: rpcinfo   2.5: etherfind and snoop   2.6 Running a snoop of NFS requests:   2.7 Lockd debug hints 3.0: Common How Tos   3.1: Exporting Filesystems Under SunOS   3.2: Exporting Filesystems Under Solaris   3.3: Mounting Filesystems Under SunOS   3.4: Mounting Filesystems Under Solaris   3.5: Setting Up Secure NFS 4.0: Some Frequently Asked Questions   4.1: Miscellaneous NFS Questions   4.2: Problems Mounting Filesystems on a Client   4.3: Common NFS Client Errors Including NFS Server Not Responding   4.4: Problems Umounting Filesystems on a Client   4.5: Interoperability Problems With Non-Sun Systems   4.6: Common NFS Server Errors   4.7: Common nfsd Error Message on NFS Servers   4.8: Common rpc.mountd Error Messages on NFS Servers   4.9: Common rpc.lockd & rpc.statd Error Messages   4.10: NFS Related Shutdown Errors   4.11: NFS Performance Tuning 5.0: Patches   5.1: Core NFS Patches for SunOS   5.2: Patches Related to NFS for SunOS   5.3: Core NFS Patches for Solaris   5.4: Patches Related to NFS for Solaris 6.0: Known Bugs & RFEs 7.0: References   7.1: Important Man Pages   7.2 Sunsolve Documents   7.3 Sun Educational Services   7.4: Solaris Documentation   7.5: Third Party Documentation   7.6: RFCs 8.0: Supportability 9.0: Additional Support   1.0: About NFS  This Tip Sheet documents a wide variety of information concerning NFS, as implemented in the SunOS and Solaris operating systems. It is intended as both an introduction to NFS and as a guide to the most common problems. There are many more complete references to NFS, a few of which are noted in section 7.4 and 7.5.  The following terms are important to an understanding of NFS:  The NFS SERVER is the machine that makes file systems available to the network. It does so by either EXPORTING (SunOS term) or SHARING (Solaris term) them.  The NFS CLIENT is the machine that accesses file systems that have been made available. It does so by MOUNTING them.  A number of different daemons are involved with NFS:  RPC.MOUNTD only runs on NFS servers. It answers initial requests from clients for file systems.  NFSD runs on NFS servers. They are the daemons that deal with the majority of the client NFS requests.  On SunOS 4.1.X, BIODS (block I/O daemons) help clients with their NFS requests.  These do not exist on Solaris 2.X.  LOCKD and STATD are a set of daemons that keep track of locks on NFS files. There will typically be a set of daemons running on a client and server.  NFS partitions can be mounted in one of two ways, hard or soft.  HARD MOUNTS are permanent mounts designed to look just like any normal, local file system. If a partition that is hard mounted becomes unavailable, client programs will keep trying to access it forever. This will cause local processes to lock when a hard mounted disk goes away. Hard mounts are the default type of mount.  SOFT MOUNTS will fail after a few retries if a remote partition becomes unavailable. This is a problem if you are writing to the partition, because you can never be sure that a write will actually get processed  on the other hand, your local processes will not lock up if that partition does go away. In general, soft mounts should only be used if you are solely reading from a disk and even then it should be understood that the mount is an unreliable one. If you soft mount a partition that will be written to, you are nearly guaranteeing that you will have problems.  There are a number of files related to NFS:  /etc/exports (SunOS) or /etc/dfs/dfstab (Solaris) lists which files to export on a Server. These file are maintained by hand.  /etc/xtab (SunOS) or /etc/dfs/sharetab (Solaris) lists the filesystems that actually are currently exported. They are maintained by exportfs and share, respectively.  /etc/rmtab on a server lists filesystems that are remotely mounted by clients. This file is maintained by rpc.mountd.  /etc/fstab (SunOS) or /etc/vfstab (Solaris) lists which files to mount on a client. These files are maintained by hand.  /etc/mtab (SunOS) or /etc/mnttab (Solaris) on a client lists filesystems which are currently mounted onto that client. The mount and umount commands modify this file.  2.0 Debugging NFS   General NFS Debugging Note  When NFS is not working or working intermittently, it can be very difficult to track down what exactly is causing the problem. The following tools are the best ones available to figure out what exactly NFS is doing.   2.1: share and exportfs  share (on Solaris) and exportfs (on SunOS) are good tools to use to see exactly how a NFS server is exporting its filesystems. Simply log on to the NFS server and run the command that is appropriate for the OS.    SunOS:   # exportfs   /usr -root=koeller   /mnt   /tmp  The above shows that /mnt and /tmp are exported normally. Since we see neither rw or ro as options, this means that the default is being used, which is rw to the world. In addition /usr gives root permissions to the machine koeller.    Solaris:   # share   -               /var   rw=engineering   ""   -               /usr/sbin   rw=lab-manta.corp.sun.com   ""   -               /usr/local   rw   ""  The above shows that /usr/local is exported normally, /var is exported only to engineering (which happens to be a netgroup) and /usr/sbin is exported only to lab-manta.corp.sun.com (which is a machine).  Note: netgroups are only supported if you are running NIS or NIS+. Consult documentation on those products for how to set up netgroups on your machines   2.2: showmount  showmount, used with the -e option, can also show how a NFS server is exporting its file systems. Its benefit is that it works over the network, so you can see exactly what your NFS client is being offered. However, showmount does not show all of the mount options and thus you must sometimes use share or exportfs, as described in section 2.1. When you do a test with showmount, do it from the NFS client that is having problems:    # showmount -e psi   export list for psi:   /var       engineering   /usr/sbin  lab-manta.corp.sun.com   /usr/local (everyone)    # showmount -e crimson   export list for crimson:   /usr (everyone)   /mnt (everyone)   /tmp (everyone)  Note that showmount only displays: the partition and who can mount it. We will not see any other options displayed. In the example above, there are no restrictions on who can mount crimson's partitions and so showmount lists (everyone).   2.3: nfsstat  The nfsstat command gives diagnostics on what type of messages are being sent via NFS. It can be run with either the -c option, to show the stats of an NFS client, or the -s option, to show the stats of an NFS server. When we run 'nfsstat -c' we see the following:    # nfsstat -c    Client rpc:   calls      badcalls   retrans    badxids    timeouts   waits      newcreds   45176      1          45         3          45         0          0   badverfs   timers     toobig     nomem      cantsend   bufulocks   0          80         0          0          0          0    Client nfs:   calls      badcalls   clgets     cltoomany   44866      1          44866      0    Version 2: (44866 calls)   null       getattr    setattr    root       lookup     readlink   read   0 0%%       7453 16%%   692 1%%     0 0%%       15225 33%%  55 0%%      13880 30%%   wrcache    write      create     remove     rename     link       symlink   0 0%%       5162 11%%   623 1%%     914 2%%     6 0%%       306 0%%     0 0%%   mkdir      rmdir      readdir    statfs   15 0%%      0 0%%       467 1%%     68 0%%  The rpc stats at the top are probably the most useful. High 'retrans' and 'timeout' values can indicate performance or network issues. The client nfs section can show you what types of NFS calls are taking up the most time. This can be useful if you're trying to figure out what is hogging your NFS. For the most part, the nfsstat command is most useful when you are doing network and performance tuning. Section 7.4 and 7.5 list books that give some information on this  they are useful to make more sense of the nfsstat statistics.   2.4: rpcinfo  You can test that you have a good, solid NFS connection to your NFS server via the rpcinfo command. As explained in the man page, this program provides information on various rpc daemons, such as nfsd, rpc.mountd, rpc.statd and rpc.lockd. Its biggest use is to determine that one of these daemons is responding on the NFS server. The following examples all show the indicated daemons correctly responding. If instead you get complaints about a service 'not responding,' there might be a problem.  To see that nfsd is responding:    # rpcinfo -T udp crimson nfs   program 100003 version 2 ready and waiting  [crimson is the name of the remote machine that I am testing]  To see that mountd is responding:    # rpcinfo -T udp crimson mountd   program 100005 version 1 ready and waiting   program 100005 version 2 ready and waiting  To see that lockd is responding:    # rpcinfo -T udp crimson nlockmgr   program 100021 version 1 ready and waiting   rpcinfo: RPC: Procedure unavailable   program 100021 version 2 is not available   program 100021 version 3 ready and waiting    # rpcinfo -T udp crimson llockmgr   program 100020 version 2 ready and waiting  (the procedure unavailable error for the nlockmgr seems to be normal for most systems)  If you run rpcinfo and determine that certain rpc services are not responding, check those daemons on the master.  If none of the above works, you can verify that RPC services are working at all on the server by running:    # rpcinfo remote-machine-name  If this gives errors too, there is probably an issue with portmap (SunOS) or rpcbind (Solaris).  [Note: the above rpcinfo commands will vary slightly under Solaris 2.5 or higher, as those OSes will offer NFS version 3, running over TCP, rather than UDP.]   2.5: etherfind and snoop  If all else fails and NFS still doesn't seem to be working right, the last resort in debugging is to use a network sniffer program, such as etherfind (SunOS) or snoop (Solaris). This can give you some indication of whether remote machines are responding at all. Below is an example of a totally normal NFS interaction, shown by snoop on Solaris:    # snoop psi and rainbow-16   Using device /dev/le (promiscuous mode)            psi -> rainbow-16   NFS C GETATTR FH=4141     rainbow-16 -> psi          NFS R GETATTR OK            psi -> rainbow-16   NFS C READDIR FH=4141 Cookie=2600     rainbow-16 -> psi          NFS R READDIR OK 1 entries (No more)  These were the results when an 'ls' was run on 'psi' in a directory that was mounted from 'rainbow-16'. The lines labelled 'C' are NFS requests, while the lines labelled 'R' are NFS replies. Through snoop you can easily see: NFS not being responding to (you would get lots of 'C' lines without 'R' replies to them) and also certain errors (timeouts and retransmits particularly). The man page on snoop gives some indication of how to make more in-depth use of the tool. In general, it should only be used for very complex issues, where NFS is behaving very oddly and even then you must be very good with NFS to perceive unexpected behavior.  See the next section for more tips on snoop.   2.6  Running a snoop of NFS requests:  This is best done from a third, uninvolved machine.  If the machine that you are trying to debug is on "systemA", then trace the packets going to and from "systemA" as follows:  snoop -o /var/snoop.out systemA  Alternatively, snoop between systemA and clientB:  snoop -o /var/snoop.out systemA clientB  snoop will run in the window (do not put into background), with a counter of the packets in the corner of the screen.  It will dump all the packets into a raw snoop file.  When the "network event" occurs, wait a couple of seconds and then kill the snoop job.  If the network event includes error messages in /var/adm/messages, please send us the /var/adm/messages and the raw snoop file (/var/snoop.out).  You can read the snoop file with snoop -i /var/snoop.out more.  There are a variety of options in the snoop man page to increase verbosity, and/or to look at specific packets.  Please note that if disk space becomes an issue, you must take steps similar to those listed above.  A very large snoop file can be created in two or three minutes, so snooping is best reserved for easily reproduced events.   2.7  Lockd debug hints  Please see section 4.9: Common rpc.lockd & rpc.statd Error Messages for information regarding specific lockd and statd problems.  Generally you can pick out problem clients by snooping and/or putting lockd into debug mode.  Sections 2.5 and 2.6 cover snoop.  How to put the Solaris 2.3 and 2.4 lockd into debug mode: Edit the line in the /etc/init.d/nfs.client script that starts up lockd to start it with -d3 and redirect stdout to a filesystem with ALOT of disk space.     /usr/lib/nfs/lockd -d3 > /var/lockd.debug.out  Note that lockd always creates an empty file in the pwd, called logfile when it is running in debug mode.  Disregard this file.  If disk space becomes an issue from doing the lockd debug mode, you will have to stop lockd and restart it.  If you turn the above command from a shell, make sure it is a bourne or korn shell (sh or ksh).  How to put the Solaris 2.5 lockd into debug mode:  You will have to do this from a shell, preferably a command tool window.  You must capture the debug output that scrolls by into a script file:    script /var/lockd.out   /usr/lib/nfs/lockd -d3  After you are done debugging, CTRL/C the lockd job since it does not fork and exec to the background.  Then exit or CTRL/D the script job.  The debug output will be in /var/lockd.out.  Please note that Solaris 2.5 will also log more detailed debug output into the /var/adm/messages file.  We will need that also.  How to run a truss of lockd (you rarely need to do this):  Just modify the start of lockd to be a truss of the lockd process. You will need even more disk space to do this!  For Solaris 2.3 and 2.4: truss  -o /var/truss.out -vall -f /usr/lib/nfs/lockd -d3>var/lockd.debug.out  For Solaris 2.5:   script /var/lockd.out   truss -o /var/truss.out -vall -f /usr/lib/nfs/lockd -d3  CTRL/C the script job (and exit from the script shell if on 2.5) after you have reproduced the problem.  If disk space becomes an issue from doing the truss, use a cron job to: 1.  stop running truss 2.  move "current" truss file to "old" truss file 3.  get PID of lockd 4.  truss -o /var/truss.out.current -vall -f -p PID (PID from step 3).  3.0 Common How-Tos   3.1: Exporting Filesystems Under SunOS  In order to export a fs under SunOS, you must first edit the file /etc/exports on your NFS server, adding a line for the new filesystem. For example, the following /etc/exports file is for a server that makes available the filesystems /usr, /var/spool/mail and /home:    # cat /etc/exports   /usr   /var/spool/mail   /home  You can add normal mount options to these lines, such as ro, rw and root. These options are fully described in the exports man page. The following example shows our /etc/exports file, but this time with the filesystems all being exported read only:    # cat /etc/exports   /usr  -ro   /var/spool/mail       -ro   /home -ro  If your machine is already exporting filesystems and you are adding a new one, simply run the exportfs command to make this new filesystem available:    # exportfs -a  If you have never exported filesystems from this machine before, you should reboot it after editing the /etc/exports file. This will cause rpc.mountd and nfsd to get started and will also automatically export out the filesystems.   3.2: Exporting Filesystems Under Solaris  You must edit the file /etc/dfs/dfstab in order to make files automatically export on a Solaris system. The standard syntax of lines in that file is:    share -F nfs partition  For example, the following /etc/dfs/dfstab file is for a server that makes available the filesystems /usr, /var/spool/mail and /home:    share -F nfs /usr   share -F nfs /var/spool/mail   share -F nfs /home  You can add normal mount options to these lines, such as ro, rw and root. this is done by proceeding the options with a -o flag. These options are fully described in the share man page. The following example shows our /etc/dfs/dfstab file, but this time with the filesystems all being exported read only:    share -F nfs -o ro /usr   share -F nfs -o ro /var/spool/mail   share -F nfs -o ro /home  If your machine is already exporting filesystems and you are adding a new one, simply run the shareall command to make this new filesystem available:    # shareall  If you have never exported filesystems from this machine before, you must run the nfs.server script:    # /etc/init.d/nfs.server start  (The NFS Server will come up fine on the next boot, now that an /etc/dfs/dfstab file exists)   3.3: Mounting Filesystems Under SunOS  You can always mount file systems with the mount command, with the following syntax:    mount remotemachine:/remotepartition /localpartition  For example:    mount bigserver:/usr/local /usr/local  You might also give the mount command any of the general mount options. For example, to mount /usr/local read only, you would use the command:    mount -o ro bigserver:/usr/local /usr/local  If you wish a filesystem to get mounted every time the machine is booted, you must edit the /etc/fstab file. The syntax is:    remotemach:/remotepart        /localpart      nfs     [options]       0 0  The options field is optional and can be left out if none are needed. To make /usr/local mount automatically, you would add the following to your /etc/fstab:    bigserver:/usr/local  /usr/local      nfs     0 0  To make it mount read only, you could use:    bigserver:/usr/local  /usr/local      nfs     ro      0 0   3.4: Mounting Filesystems Under Solaris  Section 3.3, above, shows how to correctly use the mount command, to interactively mount files. It works exactly the same under Solaris.  If you wish a filesystem to get mounted every time the machine is booted, you must edit the /etc/vfstab file. The syntax is:    remotemach:/remotepart - localpart nfs - yes [options]  For example, to mount the /usr/local partition, you would enter:    bigserver:/usr/local - /usr/local nfs - yes -  To mount it readonly, you would enter:    bigserver:/usr/local - /usr/local nfs - yes ro  Consult the vfstab man page if you're interested in knowing what the fields that contain "-"s and "yes" are for. For the most part, they're only relevant for non-NFS mounts.   3.5: Setting Up Secure NFS  NFS has built-in private-key encryption routines that can provide added security. To use this functionality, a partition must be both exported with the "secure" option and mounted with the "secure" option. In addition, either NIS or NIS+ must be available. Secure NFS will not work without one of these naming services.  To add the -secure option to the /secret/top partition on a SunOS machine, the following exports entry would be needed on the server:    /secret/top   -secure  In addition, the following fstab entry would be needed on the client:    server:/secret/top    /secret/top     nfs     rw,secure       0 0  (Solaris machines would have to have the -secure option similarly added.)  If you are running NIS+, you will not need to do anything further to access the partition, since NIS+ users and NIS+ hosts will already have credentials created for them.  If you are running NIS, you must create credentials for all users and hosts that might want to access the secure partition.  Root can add credentials for users with the following command:    # newkey -u username  Users can create their own credentials with the following command:    $ chkey  The passwd supplied to these programs should be the same as the user's passwd.  Root can add credentials for hosts with the following command:    # newkey -h machinename  The passwd supplied to newkey in this case should be the same as the machine's root passwd.  It is important to note that rpc.yppasswd must be running on your NIS server for these commands to work. In addition, push out publickey maps afterwards to make sure that the most up-to-date credential information is available.  Once this is all done, secure NFS should work on your NIS network, with two caveats: First, keyserv must be running on your client machines. If this is not the case, adjust your rc files, so that it automatically starts up. Second, if a user does not supply a passwd when logging in (due to a .rhosts or /etc/hosts.equiv for example) or if his secure key is different than his passwd, then he will need to execute the command 'keylogin' before he can access the secure NFS partition.  4.0 Frequently Asked Questions   4.1: Miscellaneous NFS Questions  Q: What version of NFS does Sun implement?  A: All of the currently supported revisions of SunOS and Solaris support NFS version 2, over UDP. In addition, Solaris 2.5 will support NFS version 3, over TCP. Although NFS version 3 is the default for Solaris 2.5 and up, the NFS will fall back to version 2 if other machines do not have version 3 capability.  Q: What do these NFS Error Codes mean (e.g. NFS write error 49)?  A: On SunOS, you can find a list of error codes in the intro(2) man page:    # man 2 intro  On Solaris, you can consult the /usr/include/sys/errno.h file. SRDB #10946, available through SunSolve also lists some of the NFS error codes.  Q: Why isn't my netgroup entry working?  A1: There are lots of factors related to netgroup. First, you must be using either NIS or NIS+, to propagate the netgroup. Second, netgroup will only work as ro or rw arguments and even then only when the ro or rw is not being used to override another ro or rw option. Netgroups can not be used as an argument to the root option.  A2: NFS requires that the "reverse lookup" capability work such that the hostname returned by looking up the IP address (gethostbyaddr) matches EXACTLY the text specified in the netgroup entry. Otherwise the NFS mount will fail with "access denied"  For example, if the NFS server has the following NIS netgroup entry:  goodhosts   (clienta,,) (clientb,,) (blahblah,,)  clienta is at 192.1.1.1 and the Server uses DNS for hostname lookups.  The NFS request to do the mount arrives from IP address 192.1.1.1 The NFS server looks up the IP address of 192.1.1.1 to get the hostname associated with that IP address.  The gethostbyaddr MUST return "clienta".  If it does not, the NFS request will fail with "access denied".  telnet from the NFS client to the NFS server and run "who am i".  The hostname in parentheses is the name that should be in the netgroup:  hackley    pts/13       Jan 24 09:21    (mercedes)  The most common cause of this failure is failure of a DNS administrator to properly manage the "reverse lookup maps" e.g. 192.1.1.IN-ADDR.ARPA.  Q:  What can you tell me about CacheFS?  A:  CacheFS is the "cache file system".  It allows a Solaris 2.X NFS client to cache a remote file system to improve performance.  For example, CacheFS allows you to be on "clienta" and cache your home directory, which is mounted via NFS from an NFS server.  Because most often CacheFS is used in conjunction with the automounter, we have some basic information on CacheFS in our automounter tips sheet (Product Support Document).  You can read more about CacheFS in the "NFS Administration Guide" and in the "mount_cachefs" man page.  Q:  Is there a showfh for Solaris to show the NFS File Handle?  A:  Yes here it is:  #!/bin/sh # # fhfind: takes the expanded filehandle string from an # NFS write error or stale filehandle message and maps # it to a pathname on the server. # # The device id in the filehandle is used to locate the # filesystem mountpoint.  This is then used as the starting # point for a find for the file with the inode number # extracted from the filehandle. # # If the filesystem is big - the find can take a long time. # Since there's no way to terminate the find upon finding # the file, you might need to kill fhfind after it prints # the path. #  if [ $# -ne 8 ]  then         echo         echo "Usage: fhfind <filehandle> e.g."         echo         echo "  fhfind 1540002 2 a0000 4df07 48df4455 a0000 2 25d1121d"         exit 1 fi  # Filesystem ID  FSID1=$1 FSID2=$2  # FID for the file  FFID1=$3 FFID2=`echo $4   tr [a-z] [A-Z]` # uppercase for bc FFID3=$5  # FID for the export point (not used)  EFID1=$6 EFID2=$7 EFID3=$8  # Use the device id to find the /etc/mnttab # entry and thus the mountpoint for the filesystem.  E=`grep $FSID1 /etc/mnttab` if [ "$E" = "" ]   then         echo         echo "Cannot find filesystem for devid $FSID1"         exit 0 fi  set - $E MNTPNT=$2  INUM=`echo "ibase=16 $FFID2"   bc` # hex to decimal for find  echo echo "Now searching $MNTPNT for inode number $INUM" echo  find $MNTPNT -mount -inum $INUM -print 2>dev/null   4.2: Problems Mounting Filesystems on a Client  Q: Why do I get "permission denied" or "access denied" when I try to mount a remote filesystem?  A1: Your remote NFS server is not exporting or sharing its file systems. You can verify this by running the showmount command as follows:    # showmount -e servername  That will provide you with a list of all the file systems that are being sent out. If a file system is not being exported, you should consult section 3.1 or 3.2, as applicable.  A2: Your remote NFS server is exporting file systems, but only to a limited number of client machines, which does not include you. To verify this, again use the command showmount:    # showmount -e psi   /var       engineering   /usr/sbin  lab-manta.corp.sun.com   /usr/local (everyone)  In this example, /usr/local is being exported to everyone, /var is being exported to the engineering group, and /usr/sbin is only being exported to the machine lab-manta.corp.sun.com. So, I might get the denial message if I tried to mount /var from a machine not in the engineering netgroup or if I tried to mount /usr/sbin from anything but lab-manta.corp.sun.com.  A3: Your machine is given explicit permission to mount the partition, but the server does not list your correct machine name. In the example above, psi is exporting to "lab-manta.corp.sun.com", but the machine might actually identify itself as "lab-manta" without the suffix. Or, alternatively, a machine might be exporting to "machine-le0" while the mount request actually comes from "machine-le1". You can test this by first running "showmount -e" and then physically logging in to the server, from the client that cannot mount, and then typing "who". This will show you if the two names do not match. For example, I am on lab-manta, trying to mount /usr/sbin from psi:    lab-manta# mount psi:/usr/sbin /test   mount: access denied for psi:/usr/sbin  I use showmount -e to verify that I am being exported to:    lab-manta# showmount -e psi   export list for psi:   /usr/sbin  lab-manta.corp.sun.com  I then login to psi, from lab-manta, and execute who:    lab-manta%% rsh psi   ...   psi# who   root       pts/6        Sep  8 14:02    (lab-manta)  As can be seen, the names "lab-manta" and "lab-manta.corp.sun.com" do not match. The entry shown by who, lab-manta, is what should appear in my export file. When I change it and re-export, I can verify it with showmount and then see that mounts do work:    lab-manta[23] showmount -e psi   export list for psi:   /usr/sbin  lab-manta   lab-manta[24] mount psi:/usr/sbin /test   lab-manta[25]  A4: Your client is a member of a netgroup, but it seems that the netgroup does not work.  See Section 4.1 for notes on debugging netgroups.  Q: Why do I get the following error when I try and mount a remote file system:    nfs mount: remote-machine:: RPC: Program not registered   nfs mount: retrying: /local-partition  A: rpc.mountd is not running on the server. You probably just exported the first filesystem from a machine that has never done NFS serving before. Reboot the NFS server, if it is SunOS 4.X,.  The the NFS server is running Solaris 2.X, run the following:  /etc/init.d/nfs.server start  Note: Consult section 3.1 or 3.2 for information on how to create the exports file on a SunOS 4.X system or on how to create the dfstab file on a Solaris 2.X system.  Q: Why doesn't the mountd respond?  After I try the mount I get NFS SERVER NOT RESPONDING.  When I try to talk to the mountd, rpcinfo gives an rpc timed out error.  How can I debug or fix a hung mountd on the NFS server.  A: First, try killing the mountd process on the server and restarting it. This gets around many hung mountd issues.  Second, make sure the NFS server is "patched up".  There is a mountd patch for Solaris 2.3 and we've seen cases where the \patch 101973 patch helps on 2.4.  Further troubleshooting tips to debug the hung mountd on Solaris 2.X: 1.  get the PID of the running mountd 2.  truss -f -vall -p PID 3.  start a snoop at the same time you start the truss 4.  if you have access to it, run "gcore" or "pstack" (unsupported utilities     made available by SunService) to get the stack trace of the mountd PID.     Update:  pstack is supported at 2.5, /usr/proc/bin/pstack .  It is              on of the new "proc" tools.  Q:  Why do I get the message "Device Busy" in response to my mount command?  A:  You get this message because some process is using the underlying mount     point.  For example, if you had a shell whose pwd was /mnt and you     tried to mount something into /mnt, e.g. mount server:/export/test /mnt     you would see this error.     To work around this, find the process using the directory and either kill     it or move its pwd someplace else.  The "fuser" command is extremely handy     to do this:     mercedes[hackley]:cd /mnt     mercedes[hackley]:fuser -u /mnt     /mnt:     4368c(hackley)     368c(hackley)      In this case you see process # 368 and 4368 are using the /mnt mount point.     PID 368  is the shell and PID 4368 was the fuser command.      You can forcibly kill any process (must be root) from a mount point     using fuser -k /mnt.      Please note that fuser is not infallible and cannot identify kernel     threads using a mount point (as sometimes happens with the automounter).   4.3: Common NFS Client Errors Including NFS Server Not Responding  If a file system has been successfully mounted, you can encounter the following errors when accessing it.  Q: Why do I get the following error message:    Stale NFS file handle  A1: This means that a file or directory that your client has open has been removed or replaced on the server. It happens most often when a dramatic change is made to the file system on the server, for example if it was moved to a new disk or totally erased and restored. The client should be rebooted to clear Stale NFS file handles.  A2: If you prefer not to reboot the machine, you can create a new mount point on the client for the mount point with the Stale NFS file handle.  Q: Why do I get the following error message:    NFS Server <server> not responding   NFS Server ok    Note, this error will occur when using HARD mounts.   This troubleshooting section applies to HARD or SOFT mounts.  A1: If this problem is happening intermittently, while some NFS traffic is occurring, though slowly, you have run into the performance limitations of either your current network setup or your current NFS server. This issue is beyond the scope of what SunService can support. Consult sections 7.4 & 7.5 for some excellent references that can help you tune NFS performance. Section 9.0 can point you to where you can get additional support on this issue from Sun.  A2: If the problem lasts for an extended period of time, during which no NFS traffic at all is going through, it is possible that your NFS server is no longer available.  You can verify that the server is still responding by running the commands:    # ping server and   # ping -s server 8000 10 (this will send 10 8k ICMP Echo request packets to the server)  If your machine is not available by ping, you will want to check the server machine's health, your network connections and your routing.  If the ping works, check to see that the NFS server's nfsd and mountd are responding with the "rpcinfo" command:     # rpcinfo -u server nfs  program 100003 version 2 ready and waiting     # rpcinfo -u server mountd  program 100005 version 1 ready and waiting program 100005 version 2 ready and waiting  If there is no response, go to the NFS server and find out why the nfsd and/or /mountd are not working over the network.  From the server, run the same commands.  If they work OK from the server, the network is the culprit.  If they do NOT work, check to see if they are running.  If not, restart them and repeat this process.  If either nfsd or mountd IS running but does not respond, then kill it and restart it and retest.  A3: Some older bugs might have caused this symptom. Make sure that you have the most up-to-date Core NFS patches on the NFS server. These are listed in Section 5.0 below. In addition, if you are running quad ethernet cards on Solaris, install the special quad ethernet patches listed in Section 5.4.  A4:  Try cutting down the NFS read and write size with the NFS mount options:  rsize=1024,wsize=1024.  This will eliminate problems with packet fragmentation across WANS, routers, hubs, and switches in a multivendor environment, until the root cause can be pin-pointed. THIS IS THE MOST COMMON RESOLUTION TO THIS PROBLEM.  A5: If the NFS server is  Solaris 2.3 and 2.4, 'nfsreadmap' occasionally caused the "NFS server not responding" message on Sun and non-Sun NFS clients.  You can resolve this by adding the following entry to your /etc/system file on the NFS server:  set nfs:nfsreadmap=0  And rebooting the machine.  The nfsreadmap function was removed in 2.5 because it really didn't work.  A6: If you are using FDDI on Solaris, you must enable fragmentation with the command: ndd -set /dev/ip ip_path_mtu_discovery 0  Add this to /etc/init.d/inetinit, after the other ndd command on line 18.  A7:  Another possible cause is IF the NFS SERVER is Ultrix, old AIX, Stratus, and older SGI and you ONLY get this error on Solaris 2.4 and 2.5 clients, but the 2.3 and 4.X clients are OK.  The NFS Version 2 and 3 protocol allow for the NFS READDIR request to be 1048 bytes in length.  Some older implementations incorrect thought the request had a max length of 1024.  To work around this, either mount those problem servers with rsize=1024,wsize=1024 or add the following to the NFS client's /etc/system file and reboot:  set nfs:nfs_shrinkreaddir=1  A8:  Oftentimes NFS SERVER NOT RESPONDING is an indication of another problem on the NFS server, particularly on the disk subsystem.  If you have a SPARCStorage Array, you must verify that you have the most recent firmware and patches due to the volatility of that product.  Another general method that can be tried to is look at the output from iostat -xtc 5 and check the svt_t field.  If this value goes over 50.0 (50 msec) for a disk that is being used to serve NFS requests, you might have found your bottleneck.  Consult the references in Section 7 of this PSD for other possible NFS Server tuning hints.  NOTE:  NFS Server performance tuning services are only available on a Time and Materials basis.  Q: Why can't I write to a NFS mounted file system as root?  A: Due to security concerns, the root user is given "nobody" permissions when it tries to read from or write to a NFS file system. This means that root has less access than any user, will only be able to read from things with world read permissions, and will only be able to write to things with world write permissions.  If you would like your machine to have normal root permissions to a filesystem, the filesystem must be exported with the option "root=clientmachine".  An alternative is to export the filesystem with the "anon=0" option. This will allow everyone to mount the partition with full root permissions.  Sections 3.1 and 3.2 show how to include options when exporting filesystems.  Q1: Why do 'ls'es of NFS mounted directories sometimes get mangled on     my SunOS machine? Q2: Why do I get errors when looking at a NFS file on my SunOS     machine?  A: By default, SunOS does not have UDP checksums enabled. This can cause problems if NFS is being done over an extended distance, especially if it is going across multiple routers. If you are seeing very strange errors on NFS or are getting corruption of directories when you view them, try turning UDP checksums on.  You can do so my editing the kernel file /usr/sys/netinet/in_proto.c, changing the following:    int  udp_cksum = 0            /* turn on to check & generate udp checksums */  to:    int  udp_cksum = 1            /* turn on to check & generate udp checksums */  Afterwards, you will must build a new kernel, install it and reboot. UDP checksums must be enabled on both the NFS client and NFS server for it to have any effect.  This is only an issue on SunOS machines, as Solaris machines have UDP checksums enabled by default.  Q1: Why do I get intermittent errors writing to an NFS partition? Q2: Why do I get intermittent errors reading from an NFS partition? Q3: Why do I get the following error on my NFS partition?    "nfs read error on <machine> rpc: timed out"  A: These symptoms can all be caused by failures of soft mounts. Soft mounts time out instead of logging an "NFS SERVER NOT RESPONDING" message.  Because of this and other reasons, it is recommended that you only mount non-critical read-only servers with soft mounts (e.g. man pages).  To resolve the problem, you must solve the underlying problem (See the section above on "NFS server not responding" for troubleshooting assistance.  Alternatively, you can mount the NFS server with hard,intr instead of soft, but this will have the effect of causing applications to hang instead of timeout when the NFS servers are unavailable or unreachable.   4.4: Problems Umounting Filesystems on a Client  Q: When I try and umount a partition, why do I get the following error:    /partition: Device busy  A: This means that someone is actively using the partition you are trying to unmount. They might be running a program from it or they might simply be sitting in a subdirectory of the partition.  In Solaris, you can run the command fuser to determine what processes are using a partition:    # fuser /test   /test:     1997c    1985c  The above example shows that pids 1985 and 1997 are accessing the /test partition. Either kill the processes or run fuser -k /test to have fuser do this for you.  NOTES:  This functionality is not available under SunOS.  It does not always identify an automounted process on Solaris.  In many cases, it is necessary to reboot a machine in order to clear out all of the processes that could be making a file system busy.   4.5: Interoperability Problems With Non-Sun Systems  The following problems are relevant to Suns that are doing mounts from non-Sun systems.  Q: Why do I get the following error when mounting from my HP or SunOS 3.5 machine or other machine running an older version of NFS:    nfsmount server/filesystem server not responding RPC authentication error \ 	why = invalid client credential.  A: Older versions of NFS only allowed users to be in eight groups or less. Reduce root's number of groups to eight or less and the problem will go away. Users planning to access this partition should also reduce their number of groups to eight.  Q: When I NFS mount filesystems to my Sun, from my PC, why does the Sun never see changes I make to those filesystems.  A: Most PC NFS servers do not seem to correctly notify their NFS clients of changes made to their filesystems. It appears that this is due to the fact that file timestamps on PCs are very coarse. If you are having this problem, speak with the vendor of your PC NFS product.  Q: Why do mounts from my SGI fail with "not a directory" ?  A: For some reason, certain versions of the SGI NFS server sometimes begin using port 860 rather than 2049 for NFS. When this occurs, mounts will fail. In order to get around this bug, always use the "port" option, with 2049 as a value, when doing mounts from an SGI, e.g.:    mount -o port=2049 sgi:/partition /localpartition  If you are mounting from an SGI via autofs, be sure you have the newest version of the kernel patch (101318-74 or better for 5.3, 101945-32 or better for 5.4), as older versions of the kernel patch did not support the port option for autofs.  Q: Why can't I NFS mount from my old, old machine?  A: If you have a very old machine, it is probably running NFS version 1. Such machines often have problems talking to newer versions of NFS. If you have a very old machine, speak with the manufacturer to see if they've ported NFS version 2 or 3.   4.6: Common NFS Server Errors  Q: Why do I get the following error when I run exportfs/shareall?    exportfs: /var/opt: parent-directory (/var) already exported   share_nfs: /var/opt: parent-directory (/var) already shared  A: NFS specs forbid you from exporting both a parent directory and a sub-directory. If you try and export a sub-directory when the parent directory is already exported, you will get the above error. The above example showed an export of the subdirectory /var/opt being attempted, after the directory /var was already available.  A very similar error will occur in the opposite case:    exportfs: /var: sub-directory (/var/spool/mail) already exported  This shows the directory /var being exported after /var/spool/mail was already available.  If you want to have both a parent directory and its sub-directory exported, you must export just the parent directory. Among other things, this means that you can not have different options on parent and sub-directories, for example -ro on a parent directory and -rw on a specific subdirectory.  Q: Why is my NFS server getting totally overrun by quota errors?  A: Solaris 2.4 experienced an error relating to way that quotas and NFS interacted.  Obtain 101945-34 or later, if quota message from NFS partitions are having a serious impact on your machine.  If you are running into this problem where your client is Solaris and your server is SunOS, you will not have this option and it is recommended that you simply upgrade your SunOS system.  Q: Why does the /etc/rmtab file get huge?  A: The rmtab contains the list of all the file systems currently being mounted by remote machines. When a filesystem is unmounted by a remote machine, the line in the rmtab is just commented out, not deleted. This can make the rmtab file get very large, maybe even filling the root partition.  If this is a problem at your site, add the following lines to your rc, prior to the starting of the rpc.mountd:    if [ -f /etc/rmtab ]   then     sed -e "/^#/d" /etc/rmtab > /tmp/rmtab 2>dev/null     mv /tmp/rmtab /etc/rmtab >dev/null 2>1   fi  This will cause the rmtab file to be trimmed every time the system boots.   4.7: Common nfsd Error Message on NFS Servers  Q: Why do I get the following error message when nfsd starts?    /usr/lib/nfs/nfsd[247]: netdir_getbyname (transport udp,        host/serv \1/nfs), Bad file number  A: This problem is usually the result of an nfsd line not being in your services map. Consult your naming service (files, nis, nis+) and insert the following entry, if it is missing:    nfsd            2049/udp        nfs             # NFS server daemon  ...and at 2.5, you must also have:   nfsd          2049/tcp        nfs  Q: Why do I get the following error message when nfsd starts?  /usr/lib/nfs/nfsd[2943]: t_bind to wrong address /usr/lib/nfs/nfsd[2943]: Cannot establish NFS service over /dev/udp: \ 		transport setup problem. /usr/lib/nfs/nfsd[2943]: t_bind to wrong address /usr/lib/nfs/nfsd[2943]: Cannot establish NFS service over /dev/tcp: \ 		transport setup problem. /usr/lib/nfs/nfsd[2943]: Could not start NFS service for any protocol. Exiting.  A: This problem is caused by trying to start a second nfsd when one is already running.   4.8: Common rpc.mountd Error Messages on NFS Servers  Q: Why do I constantly get the following error message on my NFS server:    Aug 15 13:13:56 servername mountd[930]: couldn't register TCP MOUNTPROG   Aug 15 13:13:58 servername inetd[141]: mountd/rpc/udp server failing  A: This problem occurs most often on SunOS machines. It typically means that you are starting rpc.mountd from the rc.local, but also have a line in your inetd.conf:    mountd/1       dgram   rpc/udp wait root /usr/etc/rpc.mountd   rpc.mountd  You can resolve this problem by commenting out the mountd line in the /etc/inetd.conf file and then killing and restarting your inetd.   4.9: Common rpc.lockd & rpc.statd Error Messages  Q: What does it mean when I get the following error:    lock manager: rpc error (#): RPC: Program/version mismatch  A: Some of your systems are running up-to-date versions of lockd, while others are outdated. Install the most up-to-date lockd patch on all of your systems. See section 5.0 below for a list of lockd patches.  Q: What does it mean when I get the following error:    rpc.statd: cannot talk to statd on [machine]  A: Either, [machine] is down or it is no longer doing NFS services. It's possible that the machine might still be around, but has changed its name or something similar. If these changes are going to be permanent, clear out the statmon directories on your machine. Do this by rebooting the machine into single user mode and running the following command:    SunOS:   rm /etc/sm/* /etc/sm.bak/*    Solaris:   rm /var/statmon/sm/* /var/statmon/sm.bak/*  Afterwards, execute reboot to bring your machine back up.  Alternatively, if you cannot put the system into single user mode, - Kill the statd and lockd process - clear out the "sm" and "sm.bak" directories" - Restart statd and lockd in that order  Q: How can I fix these errors?  The SunOS 4.1.X lockd reports:    lockd[136]: fcntl: error Stale NFS file handle   lockd[136]: lockd: unable to do cnvt.  the lockd error message is different on Solaris 2.3 and 2.4:    lockd: unable to do cnvt.   _nfssys: error Stale NFS file handle   Generally, this is caused by an error from a client.  The client  has submitted a request for a lock on a stale file handle.  Sometimes,  older or unpatched lockd clients will continually resubmit these  requests.  See the "lockd debug hint" Section for help in  identifying the client making the request.  See section 5.0 for info  on the NFS and lockd patches.  If the client is a non-Sun,  contact the client system vendor for their latest lockd patch.  Q: How can I fix the following errors:      nlm1_reply: RPC unknown host      create_client: no name for inet address 0x90EE4A14. We also see      nlm1_call: RPC: Program not registered      create_client: no name for inet address 0x90EE4A14.  A: There are THREE items to check in order.  1.  This first answer applies if the The hexadecimal address 0x90EE4A14     corresponds to an IP address in use on your network and it not     in your hosts database (/etc/hosts, NIS, NIS+ or DNS as appropriate).      In this case, to 144.238.74.20.     The customer does not have that host ID in his NIS+ hosts table.     The customer can find out the host name for that IP address by using     telnet to connect to the IP address, then getting the hostname.     The customer then adds the entry to the NIS+ hosts table.      Then verify that gethostbyaddr() was working with the new     IP/hostname in NIS+ with:       ping -s 144.238.74.20     The responses interpret the IP address into the hostname.  2.  If you do the above and the messages continue, kill and     restart the lockd as it appears lockd caches name service     information.  3.  Patch levels:  Solaris 2.4: 101945-34 or better kernel jumbo patch 101977-04 or better lockd jumbo patch 102216-05 or better klm kernel locking patch (See note below)  Note: Patch 102216-05 contains a fix for a bug that can cause this error message: 1164679 KLM doesn't initialize rsys & rpid correctly  Solaris 2.3: 101318-75 or better kernel jumbo patch  Q:  Why do I get the following error message on Solaris?  lockd[2269]:netdir_getbyname (transport udp, host/serv \1/lockd), Resource temporarily unavailable lockd[2269]: Cannot establish LM service over /dev/udp: bind problem. Exiting.  A:  This is caused by missing entries for lockd in /etc/services, the NIS services map, or the NIS+ services table. Verify this with: getent services lockd  If you don't get the lockd entries, add the following entry to the appropriate services database if it does not exist: lockd           4045/udp lockd           4045/tcp  Check your /etc/nsswitch.conf file's services entry to determine which services database you are using.  Q:  Why do I get the following error message on Solaris?  lockd[2947]: t_bind to wrong address lockd[2947]: Cannot establish LM service over /dev/udp: bind problem. Exiting.  A:  This is caused by trying to start lockd when it is already running. If you see this message at bootup, you must inspect your startup scripts in /etc/rc2.d and /etc/rc3.d to determine the cause.   4.10: NFS Related Shutdown Errors  Q: Why do I get the following error, when running 'shutdown' on my Solaris machine:    "showmount: machine: RPC:program not registered"  A: This is due to a bug in the /usr/sbin/shutdown command. shutdown executes the showmount command as part of its scheme to warn other machines that it will not be available. If the machine you executed shutdown on is not a nfs server, shutdown will complain with the above message. This will cause no impact to your machine, but if it annoys you, you can run the older /usr/ucb/ shutdown program:    # /usr/ucb/shutdown  Q: Why do I get the following error, when running 'shutdown' on my Solaris machine:    "nfs mount:machine(vold(PID###):server not responding:RPC not registered"  A: This is due to a bug in vold, which causes it to be shutdown too late. This will cause no impact to your machine, but if it annoys you, you can stop vold before executing shutdown:    # /etc/init.d/volmgt stop   # shutdown   4.11  NFS Performance Tuning  Q: How do I determine how many nfsds to run on a SunOS 4.1.X or on a    Solaris 2.X system?  A:  It is difficult to provide NFS tuning in short a technical note, but here are some general guidelines.  For more specific guidelines, consult the O'Reilly and Associates book "Managing NFS and NIS", the SunSoft Press book, "Sun Performance and Tuning", or the "SMCC NFS Performance and Tuning Guide".  Ordering info is in Section 7 of this PSD.  If you need NFS performance consulting assistance from SunService, please refer to Sections 8 and 9 of this document on supportability and support providers.  In SunOS 4.1.X, the number of nfsd's specifies the number of nfsd processes that run.  In Solaris 2.X, the number of nfsd's specifies the number of nfsd threads that run inside the single nfsd Unix process.  Here are some general guidelines for SunOS 4.1.X:  To determine how many nfsds to run, use any of the formulas below to pick a starting value.  Then use the procedures below to adjust the number of nfsds until it is right for the particular environment.  --------------------------------------------------------   VARIATION                    FORMULA --------------------------------------------------------  Variation 1   #(disk spindles) + #(network interfaces) --------------------------------------------------------  Variation 2   4 for a desktop system that is both                client and server,                8 for a small dedicated server,                16 for a large NFS and compute server,                24 for a large NFS-only server +-----------+------------------------------------------+  Variation 3   2 * max#(simultaneous disk operations) --------------------------------------------------------  On Solaris 2.X, this number will be different.  The SunSoft press book recommends taking the highest number obtained by applying the following three rules:  * Two NFS threads per active client process * 32 NFS threads on a SPARCclassic server, 64 NFS threads per   SuperSPARC processor. * 16 NFS threads per ethernet, 160 per FDDI  The default for 2.X is 16 threads.  Q: What other guidelines and help is there on Tuning NFS?  A:  Consult the O'Reilly and Associates book "Managing NFS and NIS", the SunSoft Press book, "Sun Performance and Tuning", or the "SMCC NFS Performance and Tuning Guide".  Ordering info is in Section 7 of this PSD.  5.0 Patches   General Information on Patches  The following is the list of all of the NFS related patches for 4.1.3, 4.1.3_u1, 4.1.4, 2.3, 2.4, and 2.5.  If you are having NFS problems, installing the patches is a good place to start, especially if you recognize the general symptoms noted below.  In order for a machine to be stable, all of the recommended patches should be installed as well. The list of recommended patches for your operating system is available from sunsolve1.sun.com   5.1: Core NFS Patches for SunOS 4.1.X  100173-13 SunOS 4.1.3: NFS Jumbo Patch 102177-04 SunOS 4.1.3_U1: NFS Jumbo Patch 102394-02 SunOS 4.1.4: NFS Jumbo Patch    Resolve a large number of NFS problems. Should be installed on any   machine doing NFS.  100988-05 SunOS 4.1.3: UFS File system and NFS locking Jumbo Patch. 101784-04 SunOS 4.1.3_U1: rpc.lockd/rpc.statd jumbo patch 102516-05 SunOS 4.1.4: UFS File system Jumbo Patch    Fixes a wide variety of rpc.lockd and rpc.statd problems.  102264-02 SunOS 4.1.4: rpc.lockd patch for assertion failed panic    Fixes an "Assertion failed" panic related to the lockd.  103275-01 SunOS 4.1.4: System with heavy NFS load may crash due to                  IP driver bu   5.2: Patches Related to NFS for SunOS  100361-04 SunOS 4.1.1 4.1.2 4.1.3: server not responding due to limits of    Resolves an error that could cause "NFS server not responding"   errors on a machine that had more than 500 machines in its arp cache.   Only a problem at sites with very large local nets.  101849-01 SunOS 4.1.3: rpc.quotad is very slow on busy NFS servers    Speeds up slow rpc.quotads on NFS servers.   5.3: Core NFS Patches for Solaris  SOLARIS 2.3:  101318-81 SunOS 5.3: Jumbo patch for kernel (includes libc, lockd)    Resolves a large number of problems involving both nfs and the   lockd, as well as the related autofs program. Should be installed   on any 5.3 machine, but is an absolute necessity on a machine doing   NFS.  102654-01 SunOS 5.3: rmtab grows without bounds    This patch solves problems where the mountd hangs up, but the nfsd   continues to process NFS requests from existing NFS mounts.  103059-01 SunOS 5.3: automountd /dev rdev not in mnttab    This patch fixes a variety of issues where the automounter loses   entries from mnttab, often seen with lofs (loopback) mounts.  101930-01 SunOS 5.3: some files may not show up under cachefs    This patch is required with the "autoclient" product, which is needed   to cache the / and /usr file systems with cachefs.  102932-02 SunOS 5.3: statd dies intermittently  SOLARIS 2.4 and 2.4x86:  101945-42 SunOS 5.4: jumbo patch for kernel 101946-35 SunOS 5.4_x86: jumbo patch for kernel    Resolves a large number of problems involving nfs, as well as the   related autofs program. Should be installed on any 5.4 machine, but   is an absolute necessity on a machine doing NFS.  102685-01 SunOS 5.4: lofs - causes problems with 400+ PC-NFS users    This patch resolves some mountd hangs seen after sharing a lofs mount point.  101977-04 SunOS 5.4: lockd fixes 101978-03 SunOS 5.4_x86: lockd fixes    Resolves various lockd error messages, as well as a lockd memory   leak.  102216-07 SunOS 5.4: klmmod and rpcmod fixes    Resolves problems with NFS file locking.  It is needed whenever   patching lockd.  102769-03 SunOS 5.4: statd requires enhancements in support of HADF    This patch is generally needed in high availability server application.  102209-01 SunOS 5.4: No way to cache the root and /usr file systems with CacheFS 102210-01 SunOS 5.4_x86: No way to cache root & /usr file systems with CacheFS    This patch is required with the "autoclient" product, which is needed   to cache the / and /usr file systems with cachefs.  102217-07 SunOS 5.4_x86: NFS client starts using unreserved UDP port numb    Resolves a problem specific to the x86 port of 5.4, which caused NFS   clients to begin using unreserved ports. [look up bug 1179403]  SOLARIS 2.5 and 2.5x86  103226-07 SunOS 5.5: /kernel/sys/nfs and /kernel/fs/nfs fixes 103227-06 SunOS 5.5_x86: /kernel: sys/nfs, fs/nfs & misc/nfssrv fixes   This patch is needed for any Solaris 2.5 system w/ NFS  103325-02 SunOS 5.5: mount causes the system to panic Data fault    This patch also fixes some file locking problems in klmmod  103477-02 SunOS 5.5: RPC: Unable to send/receive 103478-01 SunOS 5.5_x86: RPC: Unable to send/receive  SOLARIS 2.5.1, 2.5.1_x86, and 2.5.1_ppc 103609-02 SunOS 5.5.1: RPC: Unable to send/receive 103611-01 SunOS 5.5.1_ppc: RPC: Unable to send/receive 103610-01 SunOS 5.5.1_x86: RPC: Unable to send/receive   5.4: Patches Related to NFS for Solaris  We STRONGLY recommend you install these patches, especially if you have had any problems with "NFS SERVER NOT RESPONDING":  SOLARIS 2.3:  101546-01 SunOS 5.3: nfs: multiple quota -v may not return info or too slow  101581-02 SunOS 5.3: quotaon/quotaoff/quotacheck fixes   Resolves a problem that caused rquotad to hang on some NFS systems and   to resolve other quota issues.  101306-11 SunOS 5.3: Jumbo Patch for le & qe drivers   This is a "must install" patch for systems with Ethernet.  102272-02 SunOS 5.3: Ethernet and ledmainit fixes   Resolve dma problems with le interface, possible causes of NFS server hangs  101734-03 SunOS 5.3: iommu fixes for sun4m  Resolve iommu problems mainly on Sparc 5, possible causes of NFS server hangs.  SOLARIS 2.4:  101973-23 SunOS 5.4: jumbo patch for libnsl and ypbind   This patch resolves a variety of name service issues that can cause   a 2.4 NFS server to not respond to certain requests.  This is a "must have"    patch.  102001-11 SunOS 5.4: le, qe, be Ethernet driver Jumbo Patch   This is a "must install" patch for systems with Ethernet.  102332-01 SunOS 5.4: ledma fix   Resolve dma problems with le interface, possible causes of NFS server hangs  102038-02 SunOS 5.4: iommunex_dma_mctl Sparc 5 only   Resolves iommu problems on Sparc 5, possible causes of NFS server hangs.  SOLARIS 2.5  102979-02 SunOS 5.5: /kernel/drv/be, /kernel/drv/hme and /kernel/drv/qe fixes 103244-03 SunOS 5.5: Fix for le driver  6.0 Bugs and RFEs   Bugs and RFEs (Request for Enhancement)  This section should be considered under construction and fairly dynamic.  Bugs:  1149389 - Under heavy load, a 2.3 NFS server may see the following errors: Oct 18 08:57:12 cobra unix: xdrmblk_getmblk failed Oct 18 08:57:12 cobra unix: NOTICE: nfs_server: bad getargs  There is no fix for this bug in 2.3.  One case of this bug was fixed in the 2.4 FCS.  Note:  it is possible that this bug is caused by UDP checksum errors from the clients.  This is most often seen with SunOS and PC clients.  Enable UDP checksumming as a potential workaround.  Another workaround is to change the rsize=1024,wsize=1024 on all of the NFS client so that there is no UDP packet reassembly problems.  In any case, the root cause is corruption of a UDP packet or incorrect or non-existent creation of UDP checksums for requests from an NFS client.  See the automount Tips Sheet "PSD" for some further information about automount bugs.  1174737   2.4 NFS clients hang with logging in to NFS mounted home directory,           even though the NFS clients and server are "patched up". Workaround: Upgrade the 2.4 NFS client to 2.5.  Alternatively, make the ksh shell history file local, by editing in the /etc/profile on the NFS clients:  export HISTFILE=/tmp/$LOGNAME  1222181   2.4's mountd allows automount "lofs" mount point created by loopback mount to be shared or exported.  This bug has been known to cause mountd hangs on 2.4!!  RFEs:  To be investigated and added  7.0 Documentation   7.1: Important Man Pages    dfmounts              (Solaris only)   dfshares              (Solaris only)   exportfs   exports   lockd   mnttab   mount   mountd   nfs   nfsd   rmtab   share                 (Solaris only)   share_nfs             (Solaris only)   shareall              (Solaris only)   sharetab              (Solaris only)   showmount   statd   xtab   unshare               (Solaris only   7.2 Sunsolve Documents  There are a huge number of Sunsolve documents related to NFS. The ones noted below are primarily those that have expanded information, not in this document.  7.2.1 Sun Infodocs  2016      How does NFS work?  7.2.2 Sun FAQs  1025      nfs mounting from non-Solaris system fails  7.2.3 Sun SRDBs  3874      Getting "Stale NFS Handles" errors 4456      What is the procedure for optimizing the number of nfsds? 4726      error running exportfs: "Too many levels of remote in path" 4727      exportfs doesn't recog. netgroup root access exported dir. 4769      How to use rpcinfo program to troubleshoot RPC daemons? 4840      Secure NFS failing with authentication errors 5594      nfs mount fails with "not owner" 5925      NFS request from unprivileged port. 6682      quota -v return no information on an NFS client 7334      rpc.lockd error- fcntl: error Stale NFS file handle 10609     diskless client boot gave nfs mount error 13 10946     NFS errors 11058     ls of file system mounted from ULTRIX server hangs on Solaris 2.4   7.3 Sun Educational Services  Sun Education provides general SunOS and Solaris network administration classes.  In the USA, contact Sun Education at 1-800-422-8020 for a current catalog and set of course descriptions.   7.4: Solaris Documentation  _NFS Administration Guide_, Part #801-6634-10    Information on how to set up, maintain and debug NFS and   autofs.  _SMCC NFS Server Performance and Tuning Guide_, Part #802-5010-10    A very good resource for analyzing and improving NFS performance on   a Solaris server.    The part number shown is for the Solaris 2.5 version of this manual.   7.5: Third Party Documentation  _Managing NFS and NIS_, by Hal Stern, published by O'Reilly & Associates, Inc, ISBN #0-937175-75-7    The definitive source for managing NFS in a SunOS environment. Has a   section on performance tuning that is quite helpful. Gives some   information on the automounter as well. The underlying concepts are   still the same for Solaris, but some of the commands and file names   have changed.  _TCP/IP Network Administration_, by Craig Hunt, published by O'Reilly & Associates, Inc, ISBN #0-937175-82-X    A good overview of TCP/IP, with a limited introduction to SunOS NFS.   7.6: RFCs  RFCs are the internet-written documents that define the specifications of many common networking programs. RFCs can be retrieved from nic.ddn.mil, in the /rfc directory.  1094  NFS: Network File System Protocol specification    The official spec on the NFS protocol.  8.0 Supportability   8.0: Supportability  SunService is not responsible for the initial configuration of your NFS environment. In addition, SunService can not diagnose your NFS performance problems or suggest NFS tuning guidelines.  Consulting services are available from Sun to provide these services on a flat fee or per hour consulting rate.  Contact your local Sun office for further information on those services.  We can help resolve problems where NFS is not behaving correctly, but in such cases the contact must be a system administrator who has a guarantee a solution to problems involving non-Sun hosts, nor    PATCH ID: n/a PRODUCT AREA: Gen. Network PRODUCT: NFS SUNOS RELEASE: any UNBUNDLED RELEASE: n/a HARDWARE: n/a  
INFODOC ID: 11990  SYNOPSIS: AUTOMOUNTER PSD/FAQ DETAIL DESCRIPTION:  SunService Tip Sheet for the Sun Automounter  Revision: 1.5 Date: June 18, 1996  Mail to: brian.hackley@east.sun.com  Table of Contents:  1.0: About the Automounter 2.0: Debugging the Automounter   2.1: Testing NFS   2.2: Turning on Automounter Debugging   2.3: Testing New Maps Under Solaris 3.0: Common How Tos   3.1: How to Set Up a SunOS Automount Client Using Files   3.2: How to Set Up a SunOS Automount Client Using NIS   3.3: How to Set Up a Solaris Automount Client Using Files   3.4: How to Set Up a Solaris Automount Client Using Naming Services   3.5: How to Modify Automount Maps Under NIS   3.6: How to Modify Automount Maps Under NIS+   3.7: How to Create New NIS Automount Maps   3.8: How to Create New NIS+ Automount Maps   3.9: How to Make Changes to SunOS Automounters   3.10: How to Make Changes to Solaris Automounters   3.11: How to Upgrade Automount from SunOS to Solaris   3.12: How to use cachefs With the Automounter 4.0: Some Frequently Asked Questions   4.1: Miscellaneous Questions   4.2: Automount Startup Errors   4.3: Automount Runtime Errors   4.4: Automount Shutdown   4.5: /home Problems   4.6: /net Questions   4.7:  How do I tell automount NOT to use a certain map? 5.0: Patches   5.1: SunOS Patches for Automount   5.2: Solaris Patches for Automount 6.0: Known Bugs & RFEs   6.1: Bugs 7.0: References   7.1: Important Man Pages   7.2 Sunsolve Documents   7.3 Sun Educational Services   7.4: Solaris Documentation   7.5: Third Party Documentation   7.6: RFCs 8.0: Supportability 9.0: Additional Support   1.0: About the Automounter  This Tip Sheet documents a wide variety of information concerning the automounter, as implemented in the SunOS and Solaris operating systems. It is intended as both an introduction to the automounter, and as a guide to the most common problems. There are many more complete references to automounter, a few of which are noted in sections 7.4 and 7.5.  Before trying to run the automounter, you must already have a good understanding of NFS in general. SunService does have another Tip Sheet discussing general NFS topics.  The following terms are important to an understanding of the automounter:  THE AUTOMOUNTER is a program which automatically does mounts and unmounts of designated NFS partitions. It has MAPS which list what directories it controls in this manner. Automounted directories start out unmounted, are mounted when someone tries to access them, and eventually timeout, and are unmounted, when people stop using them.  There are two types of automounter maps: direct and indirect. A DIRECT MAP lists a set or unrelated mount points which may be spread out across the filesystem. A complete path (ie, /usr/local/bin or /usr/man) is listed in the map as a mount point. An INDIRECT MAP sets aside a directory, and mounts everything in the map into that directory (ie, the auto.home map sets aside /home, and everything in the auto.home map is mounted under that directory).  Automounter maps are typically distributed via a naming service, such as NIS or NIS+, so that changes can be made in one central location.  Automount between SunOS and Solaris only has one real difference: the files and maps have dots (.s) in them under SunOS (ie auto.master, auto.home), while the files/maps have underscores (_s) in them under Solaris (ie auto_master, auto_home). This change was made so that the automount maps could work correctly under NIS+.  2.0 Debugging the Automounter   General Information on Debugging the automounter  Automounter problems usually manifest as an inability to cd into a directory that should be automounted.  You should first of all look through your files and maps, making sure that they are all connected correctly, and have the right info. For example, if auto.direct is not getting read right, you should verify that auto.master references it. On Solaris, you might need to check the nsswitch.conf as well, to make sure that the automounter is using the right naming service. Consult Sections 3.1 through 3.4 for examples of proper setups.  In addition, if you are having problems with some new automounter info, you may need to restart automounter (see Section 3.9 and 3.10 for more info). If all of this seems correct, the following sections describe some additional techniques that may be used to debug the automounter   2.1: Testing NFS  If you are having problems with an automounter directory, you should always try and mount the partition by hand, to verify that the problem is related to automounter, and not NFS in general.  To do this, look in your auto.* maps, and see what remote partition your automounter is trying to access. Then, run mount to access it:    # mkdir /tmpmnt   # mount remotemachine:/partition /tmpmnt  If this generates errors, your problems is with NFS. SunService has a seperate NFS Tip sheet which describes common NFS problems, and how to debug them.  If this mount works fine, the problem is with automounter   2.2: Turning on Automounter Debugging  automounter also has built in debugging, which can be used to examine exactly what the automounter is doing. It is best to kill automount and restart it with the debug flags, so that you can see everything from the start:    SunOS:   # automount -v -TT    Solaris 2.3:   # automountd -vTT   # automount -v    Solaris 2.4 and 2.5 in a /bin/sh or /bin/ksh to redirect to a file:   # automountd -vTT 2> /var/automount-debug-file  If you do not wish to kill the automounter, you can instead enable some debugging with the following commands:    # ls /net/=2   # ls /net/=v  [The above "ls"es may not work in some cases. If this occurs, you should simply restart automount as noted above.]  After debugging has been enabled, output will start appearing on your console (Solaris 2.3 or earlier) or in your current window (Solaris 2.4). You will see lots of instances of mounts and unmounts, but should look, in particular, for errors that are recorded when you try and access the trouble automount directory.   2.3: Testing New Maps Under Solaris  Under Solaris, if you are having problems with a brand new map, you can run automount with the -v flag. This will tell you what automount is doing as it tries to create autofs mount points for new maps:    # automount -v  You can also look in the /etc/mnttab file for your automount map definitions.  TIP:  if you don't see the map definition in /etc/mnttab (or /etc/mtab for SunOS), there is something wrong with it.  Here is the map definition for an indirect map entry from the master file for /autohome1   auto.home1:  auto.home1      /autohome1      autofs  ignore,indirect,dev=28c0002     81842871  ...and here is an example mount using that map:  ace:/home1/ace  /autohome1/ace1 nfs     dev=2880002     818428801  3.0 Common How-Tos   3.1: How to Set Up a SunOS Automount Client Using Files  Under SunOS, the automounter is centered around the file /etc/auto.master. This file must contain a number of lines in the following format:    directory     mapname options  Where: directory is the directory to mount an indirect map in, or /- for a direct map  mapname is the file which contains the map  and options are any standard NFS options which should be used for the entire map. An example of an auto.master file follows:    %% cat /etc/auto.master   /-    /etc/auto.direct        -ro   /home /etc/auto.home  In this example, /etc/auto.direct will be a direct map, which mounts a number of filesystems readonly, while /etc/auto.home will be a indirect map, which mounts filesystems under the /home directory.  A typical map contains a number of lines as follows:    mountpoint    [options]       remotemachine:/remotelocation  The [options] can be omitted if only the standard options should be used. montpoint will be a full path for a direct mount (/usr/local) or just a directory name for an indirect mount (joe).  For example, the auto.direct map may read:    %% cat /etc/auto.direct   /usr/man      -soft   server:/usr/man   /usr/local            server:/export/sunos/usr/local  This would create automount points for /usr/man and /usr/local, and /usr/man would be mounted soft.  While the auto.home map (or any indirect map) would look something like this:    %% cat /etc/auto.home   joe           server:/export/home/joe   fred          server:/export/home/fred  This would create automount points for /home/joe and /home/fred.  Please note that automount will use an auto.master NIS map by default. Thus, to force automounter to use local files, you must start is as follows:    # automount -f /etc/auto.master &  You will also want to modify the automount startup in /etc/rc.local.   3.2: How to Set Up a SunOS Automount Client Using NIS  To force your automounter to read in NIS maps, you must change the way that the mapname is referenced in your auto.master file. If the mapname is listed without any "/"s, NIS maps will be automatically checked. The following auto.master file says to get the direct listing from the auto.direct NIS map, and the /home listing from the auto.home NIS map:    # cat /etc/auto.master   /-    auto.direct     -ro   /home auto.home  (Compare this to Section 3.1, where the mapname column of the /etc/auto.master map contains "/"s, directing the automounter to a local path.)  In order to get a SunOS client to start automount, using the NIS maps, all you need to do is either create an auto.master map in NIS, and distribute it (See Section 3.5), or create a local map, as noted above. Other maps should be created on the NIS master, with the same format as is described in Section 3.1 (see Section 3.5 for how to modify those NIS maps).  Afterwards, simply reboot the machine, or start up automount:    # automount &  [As a note, you may also read in NIS maps by putting a +mapname entry, ie +auto.home, in a local file  this is usually done to set up a unique automounter on a certain machine. The references in Section 7.0 should be used if you wish to implement a more complex set up, such as this.   3.3: How to Set Up a Solaris Automount Client Using Files  Follow the instructions in Section 3.1, but be aware that under Solaris, the names of the files are expected to contain "_"s instead of "."s. ie:    /etc/auto_master   /etc/auto_direct   /etc/auto_home  So, using only files, your auto_master should look something like this:    # cat /etc/auto_master   /-    /etc/auto_direct        -ro   /home /etc/auto_home  The other files would follow with the same format as described in Section 3.1.  When everything is set up, you can get automount starting by rebooting the machine, or running:    # /etc/init.d/autofs start   3.4: How to Set Up a Solaris Automount Client Using Other Naming Services  If the /etc/auto_master file contains mapnames without "/"s, additional naming services are consulted, according to the order listed in the nsswitch.conf. For example, the following /etc/nsswitch.conf line would say to check first files, then NIS:    automount:  files nis  In addition, the local files may say to read other naming services, by listing the entry "+mapname".  Following is an extremely typical automount setup for Solaris:    # cat /etc/auto_master   +auto_master   /net            -hosts          -nosuid   /home           auto_home  [The +auto_master line says to first check naming services (NIS/NIS+) for an auto_master map. Afterwards, it includes a special net map, which is described in the man page, and also a /home indirect map, which is read from the naming services.]    # cat /etc/auto_home   +auto_home  [This file says to just go out to naming services. It is necessary because "files" is one of the options listed in the nsswitch.conf.]    # ypcat auto_master   [any additional auto_master entries are listed here]   # ypcat auto_home   ...   [the full auto_home map is here]  [Thus you will need to setup all of your normal maps in NIS or NIS+, as is described in Sections 3.5 and 3.6.]  Of special note here is this: If NIS is listed as the naming service, and automountd can't find an auto_map, then it will try instead to lookup auto.map, since that is the older NIS standard. So, the above would work fine if you were using NIS, and the actual NIS map was auto.home.  When everything is set up, you can get automount started by rebooting the machine, or running:    # /etc/init.d/autofs start   3.5: How to Modify Automount Maps Under NIS  The auto.master and auto.home maps are automatically part of NIS. To distribute these maps, simply edit the files /etc/auto.master and /etc/auto.home on the master, using the format described in Section 3.1, and then make the maps to distribute them:    # cd /var/yp   # make  Section 3.7 describes how to create new NIS maps.   3.6: How to Modify Automount Maps Under NIS+  The auto_master and auto_home tables are automatically part of NIS+. They may be modified, using the format described in Section 3.1. The auto_home table may be modified via admintool, nistbladm or nisaddent (admintool is suggested). The auto_master table may be modified via nistbladm or nisaddent. nisaddent is probably the best options for making this modification.  To make a modification with nisaddent, you should first dump your map to a text file:    # /usr/lib/nis/nisaddent -d -t auto_master.org_dir key-value > /etc/auto_master.nisplus  Then, you can edit the file with your favorite editor. Remember to use only tabs between the fields, not embedded spaces:    # cat /etc/auto_master.nisplus   +auto_master   /net            -hosts          -nosuid   /home           auto_home  Afterwards, run nisaddent again to replace the NIS+ map with your text file:    # /usr/lib/nis/nisaddent -r -f /etc/auto_master.nis -t auto_master.org_dir key-value  Section 3.8 describes how to create new NIS+ maps   3.7: How to Create New NIS Automount Maps  The following example explains how to create an auto_direct map under NIS. Other new maps can be created with similar syntax.  In order to create an auto.direct map, you need to make a new entry in /var/yp/Makefile for auto.direct, mimicking the already existing auto.home entry:    auto.direct.time:  $(DIR)/auto.direct         -@if [ -f $(DIR)/auto.direct ]  then                 sed -e "/^#/d" -e s/#.*$$// $(DIR)/auto.direct                   $(MAKEDBM) - $(YPDBDIR)/$(DOM)/auto.direct                  touch auto.direct.time                  echo "updated auto.direct"                  if [ ! $(NOPUSH) ]  then                 $(YPPUSH) auto.direct                          echo "pushed auto.direct"  \                 else                 :                   fi         else                 echo "couldn't find $(DIR)/auto.direct"          fi  NOTE: all INDENTED $lines in the Makefile entry MUST be indented with the TAB key, without any imbedded spaces!!  In addition, auto.direct must be added to the all: line, near the top of the Makefile:    all: passwd group hosts ethers networks rpc services protocols         netgroup bootparams aliases publickey netid netmasks c2secure         timezone auto.master auto.home auto.direct  And, finally, near the bottom, the following line must be added:    auto.direct: auto.direct.time  [Be very careful if you just copy the above lines -- Makefile entries MUST begin with TABS, not spaces  if you text copy the above, you will end up with spaces at the beginning of each line, and make will fail.]  When this is all done, you may create an /etc/auto.direct map, put the appropriate files in it, and then do a Make:    # cd /var/yp   # make  After you have done the first make, you will probably gets some errors like the following:    "can't bind master to send ypclear message to ypserv for map ..."  This occurs because NIS is confused due to the maps not existing on the slave machines. To resolve this, you must manually copy the map to the slaves. This can be done by copying /var/yp/`domainname`/auto.direct.* from the master to /var/yp/`domainname` on each of the slaves, using either rcp or ftp.  Afterwards, do a second make:    # cd /var/yp   # make   3.8: How to Create New NIS+ Automount Maps  The following example explains how to create an auto_direct map under NIS+. Other new maps can be created with similar syntax.  STEP ONE: create a new auto_direct table, on the master server:     # nistbladm -c automount_map key=S value=S auto_local.org_dir.`domainname`.  STEP TWO:  set the group ownership of the table:     # nischgrp admin.`domainname`. auto_local.org_dir  STEP THREE:  set the correct permissions.     # nischmod n=r, o=rmcd,g=rmcd, w=r auto_local.org_dir  STEP FOUR:  create a text file, and read it into NIS+, just as is described in section 3.6:    # cat /etc/auto_local.nisplus   /usr/local/bin        server:/usr/local/bin   /usr/local/lib        server2:/usr/local/lib   # /usr/lib/nis/nisaddent -r -f /etc/auto_local.nisplus     -t auto_local.org_dir key-value  STEP FIVE:  verify the data is in the map:   # niscat -m auto_local.org_dir    (your data should display)  NOTE:  You will also want to add an entry to your NIS+ auto_master map, as is described in 3.6.   3.9: How to Make Changes to SunOS Automounters  Many changes to the Automounter will take place at once. There are two exceptions: if an automounted filesystem (or group of filesystems) is changed, that change will not take place until the filesystem (or the filsystem group) is unmounted and remounted  if a change is made to the auto.master map, or to a direct map, those changes will not take place until the automounter is restarted.  If you want to make sure that your new changes are available, your best option is to reboot the client machine running automounter.   3.10: How to Make Changes to Solaris Automounters  As with the SunOS automounter, the Solaris automounter will not see changes to already mounted partitions, the auto_master file, and direct maps. (See Section 3.9).  You must still wait for already mounted partitions to get umounted in orderto see changes on them.  However, you can force auto_master and direct map changes to get immediatelly recognised by running automount from the command line:    # automount -   3.11: How to Upgrade Automount from SunOS to Solaris  To upgrade your Automounter from SunOS to Solaris, you must first change your map names from using dots to underscores. ie:    auto.direct -> auto_direct   auto.home -> auto_home  Make sure you change all references inside the files as well.  Another common problem involves the /home directory. SunOS machines often used it as a normal directory, while Solaris typically uses it as an automounter point.  If you prefer to use /home as a normal directory, disable the /home automounting, by removing /home lines from all of your auto_direct files:    # cat /etc/auto_master   +auto_master   /net            -hosts          -nosuid   # /home           auto_home  [make sure to modify NIS or NIS+ maps too, if necessary]  If you prefer to use /home as an automount point, move everything in /home to a new directory (/export/home) and then set up an auto_home map which references that directory:    # cat /etc/auto_home   joe   machine:/export/home/joe   fred  machine:/export/home/fred   3.12: How to use cachefs With the Automounter  cachefs may be used with the automounter. The following example shows a direct cachefs map being created:    %% cat /etc/auto_master   ...   /-    /etc/auto_new    %% cat /etc/auto_new  /mydir -fstype=cachefs,cachedir=/var/mycache,backfstype=nfs  remotemachine:/dir  NOTE:  we put the "-fstype..." options into the auto_new map because a bug exists at 2.3 and 2.4 where any "fstype" options in the master map are ignored.  This bug is fixed in 2.5.   3.13: How to automount into an existing directory  If you want to automount something like /tools/compilers into an existing /tools directory, use a direct map such as:    # cat /etc/auto_master   ...   /-    /etc/auto_direct    # cat /etc/auto_direct   ...   /tools/compilers  -rw,hard,intr remotemachine:/opt/compilers  If you had used an indirect map (e.g. /tools /etc/auto_tools in the master map), the existing directory would be overlaid by /tools and disappear!  Therefore, use a direct map for EXISTING directories that you wish to use.  4.0 Frequently Asked Questions   Regarding this Section  Many apparent automount problems will actually be due to deeper NFS problems. Many of these are covered in the NFS Tip Sheet. If none of the problems listed below are familiar, you might want to see if other NFS services are also having problems, and examine the NFS Tip Sheet   4.1: Miscellaneous Questions  Q: Why does my entire automounter lock up under SunOS, whenever one automounted partitions becomes unavailable?  A: This is a design limitation of the automounter under SunOS. There is no work around for it. If you upgrade your machine to Solaris, you will find that automount reacts much better to individual partitions becoming unavailable.  Q1: What is this /tmp_mnt directory? Q2: Why does SunOS use /tmp_mnt when Solaris doesn't? Q3: How do I get rid of the /tmp_mnt directory?  A: If you are using the automounter under SunOS, whenever you do pwd or df, you will always see that your fileystem is mounted on /tmp_mnt. This is part of the functionality of SunOS automounter. You can work around the pwd problem in csh with the following alias:    # alias pwd echo \$cwd  If you wish this to be permanent, you can add the following to your .cshrc:    alias pwd (echo $cwd)  If the /tmp_mnt directory is causing you other problems, you should simply mount the partition through normal NFS.  In addition, if you upgrade your machine to Solaris, you will find that it does not have to go through the /tmp_mnt directory.  Q: Why is automount taking up lots of CPU time?  A: umount is a fairly expensive operation, and automount does it regularly. If you find that automount is taking up too much CPU, and you have all the listed automount and NFS patches installed, you are probably running into the limitations of your current setup. You can work around it by increasing the timeout value of automount (this is the length of time before automount will unmount an unused partition).  On a SunOS machine, edit the automount line of /etc/rc.local. The following line increases the automount timeout to 3600 seconds, or 60 minutes:    automount -tl 3600 &&            echo -n ' automount'  On a Solaris machine, edit the automount line of /etc/init.d/autofs. The following line increases the automount timeout to 3600 seconds, or 60 minutes:    /usr/sbin/automount -t 3600                             # do mounts  The above two fixes are only workarounds. Your system probably will still have some performance problems which SunService is unable to help you resolve. Sections 8.0 and 9.0 explain your alternatives in this case.  Q: Should I use dots or underscores in my map names!?  A: In general, use dots under SunOS and underscores under Solaris. The following two fallbacks make this easier to do:  If an auto_map is distributed via NIS+ in YP-compatibility mode, an auto.map will also be distributed.  If a Solaris machines looks up auto_map in NIS, and can not find it, it will also try and look up auto.map.  In cases when neither of these apply (ie, if you have a Solaris NIS server), your clients should use either dots or underscores, according to what your NIS/NIS+ server uses.  Q: Should I specify mount options in the auto.master file, or the subfile (ie auto.home)?  A: You can specify mount options in either (or both). The last option encountered will be the one that's used. If you need a mount option to be global for a map, you should put it in the auto.master file. If you need it to be specific for a mount, you should put it in the subfile (ie auto.home).   4.2: Automount Startup Errors  Q: What does the following error mean:    "automount: /directory/name: Not a directory"  A: This usually means that /directory/name, which is a mount point listed in one of your auto.* files, either is a file or a symbolic link. It must be a directory.  Q: What does the following error mean:    "automount: Can't get my address"  A: Your current naming service does not have an entry for your hostname. Correct this in files/NIS/NIS+/DNS as appropriate.   4.3: Automount Runtime Errors  Q: What does the following error mean:    "automountd: server [machine] not responding"  A: This correlates to the standard "NFS server [machine] not responding" error. This can mean a number of things, including (1) [machine] is down, or otherwise unavailable (2) you are experiencing certain old NFS bugs, which are corrected by the NFS patches listed in the NFS Tip Sheet (3) you are experiencing a NFS performance problem. If this is a performance problem, you will usually find that automounted partitions are very slow to access, and the "not responding" error appears intermittently. In the case of performance problems, SunService can do nothing further  Sections 8.0 and 9.0 explain your other options.   4.4: Automount Shutdown  Q: How should I kill the automounter?  A: Always give automounter a "friendly kill"  never kill -9. This will allow the automounter to clean up all those symlinks and umount those file systems. Busy mounts are NOT left alone, after a valiant attempt to umount. What happens is this: automount spawns a child to service any NEW requests to the automounte and the parent spends its time trying to umount all busy mounts.  Note: if you do a kill -9 at this point you WILL have to clean up your mess (remove symlinks, umount old automount NFS mounts, and clear up /tmp_mnt).   4.5: /home Problems  Q: Why are my /home mounts not working?  A: It is common for /home mounts to fail because something has been put in the /home directory of the problem client. Make sure that the /home directory is totally empty before the automounter is started.   4.6: /net Questions  Q: Can you explain the /net -hosts entry in the auto_master file?  A: The -hosts map is a special case of an indirect map, that provides for the dynamic mounting of a host upon reference. It is usually referenced as:  	cd /net/hostname  If you start the automounter with /net -hosts, the automounter will do the following for you:  When you reference a pathname, e.g. ls -l /net/hostname, and the hostname is an NFS server, the automounter will do an NFS mount of all exported filesystems on that NFS server for you, place the physical mount into /tmp_mnt/hostname, and let you access that NFS server thru a symlink, /net/hostname -> /tmp_mnt/net/hostname. You access the NFS files thru the /net/hostname symlink and do not need to worry about managing NFS mounts.   4.7:  How do I tell automount NOT to use a certain map?  Q:  I have a local /home directory on a certain host, that I do     not want the automounter to overwrite.  How do I tell automount     NOT to use a certain map?  A:  Create an /etc/auto_master, if one does not already exist.     Move the "+auto_master" entry to the BOTTOM of the file.     Change (or add) the /home entry so that it reads as follows: /home -null     This tells the automount to NOT create a /home map, which will     allow you to use a local /home directory on the host.      IMPORTANT:  you may NOT specify "-null" anywhere EXCEPT the     master map!  You can exclude an entire map, but NOT     individual entries within a map.  5.0 Patches   5.0: Patches  The following is the list of all of the automount related patches for 4.1.3, 4.1.3_u1, 4.1.4, 5.3 and 5.4. If you are having automount problems, installing the patches is a good place to start, especially if you recognize the general symptoms noted below.  In order for a machine to be stable, all of the recommended patches should be installed as well. The list of recommended patches for your operating system is available from sunsolve1.sun.com.  There are also a number of NFS patches which are described in the NFS Tip Sheet. All of the Core NFS patches described there should be installed as well   5.1: Automount Patches for SunOS  100249-14 SunOS 4.1.2,4.1.3: automounter jumbo patch    Fixes a very large number of automounter errors, including a big   memory leak. Should be installed on any machine running automount.  102684-02 SunOS 4.1.3_U1: automounter problems when many filesystems shar    Resolves a problem where a SunOS machine could fail to automount   from a Solaris server with the error "RPC: can't decode results".  103467-01 SunOS 4.1.4: Automount fails with replicated filesystems   5.2: Automount Patches for Solaris  SOLARIS 2.3:  101318-81 SunOS 5.3: Jumbo patch for kernel (includes libc, lockd)    Resolves a very large number of autofs and nfs problems. Should   be installed on any machine, but are an absolute necessity for   machines running automount.  103059-01 SunOS 5.3: automountd /dev rdev not in mnttab    This completes the fixes for this problem (except when using AFS)  SOLARIS 2.4 and 2.4x86:  101945-42 SunOS 5.4: jumbo patch for kernel 101946-35 SunOS 5.4_x86: jumbo patch for kernel    Resolves a very large number of autofs and nfs problems. Should   be installed on any machine, but are an absolute necessity for   machines running automount.  atch-ID#  SunOS 5.4_x86: automounter fixes     Fixes problems with automounter related to 4.1.3 interoperability   and NIS+. Should be installed on any systems having troubles with   either 4.1.3 or NIS+.  Solaris 2.5 and 2.5x86:  103048-03 SunOS 5.5: automountd fixes  SunOS 5.5x86 automountd fixes    Adds support for the "retry" parameter at 2.5   Fixes 1211172 "dev ... rdev not in mnttab" problem with lofs mounts  103492-01 SunOS 5.5: autofs is not MT-safe  6.0 Bugs and RFEs   Notes about Bugs and RFEs (Request For Enhancement)  The following bugs & RFEs reflect currently open issues with the automounter   6.1: Bugs  1151774 extra spaces and tabs in /etc/mnttab cause odd things to happen    As you can guess by the problem description, the automounter will   do odd things like unmount a directory and never mount it again.    The workaround is to clear out ANY and ALL whitespace from the   automount map entries, and use only the TAB key to seperate   the elements on a line e.g. /homeTAB-retry=2TABauto_homeRETURN  1220400 lofs becomes confused about where the present working directory "."    If you use autofs to mount local file systems on a Solaris machine,   pwd will give you the error "cannot determine current directory!"   while df . will give you the error "cannot canonicalize .: Error 0".   These are due to a bug in automount under 2.4. They should have no   other adverse effects. This is fixed under 2.5, but will not be   patched under older OSes.   NOTE:  This will be fixed in 101945-37  1226421, 1211172, 1207102 "dev... rdev... not in mnttab"    There are several circumstances in which the Solaris 2.3 and 2.4   automounter encounter these bugs.  They are fixed in 2.5 (except   if the mount is an Andrew File System AFS mount).   To solve this problem:  upgrade any and all automount clients to   the latest kernel jumbo patch.  If after doing this,   you still encounter the problem, it should only occur with a lofs   (loopback) mount, or an AFS mount.   If that is the case, there might be a T-patch available to fix the   error message.   NOTE: Patch 103059-01 fixes the lofs mount problem on 2.3!         Patch 101945-37 will fix the lofs mount problem on 2.4.   6.2: RFEs  We still need to provide this information - under construction  7.0 References   7.1: Important Man Pages  automount automountd      (Solaris only)   7.2: Sunsolve Documents  There are a number of Sunsolve documents concerning the automounter. The ones listed below are simply those which contain some amount of information which is not already in this document.  7.2.1: Sun Infodocs  2090   How Does One Customize the Automounter Setup?  7.2.2: Sun SRDBs  3033   automounter gobbling cpu time 3073   Compiler embeds/tmp_mnt automounter in  .stab entries 4087   Using automounter with PCNFS 3.5   7.3: Sun Educational Services  [pending   7.4: Solaris Documentation  _NFS Administration Guide_, part #801-6634-10    Information on autofs setup and administration under Solaris.  _Network and Administration_    Manual for SunO   7.5: Third Party Documentation  _Managing NFS and NIS_, bu Hal Stern, published by O'Reilly & Associates, ISBN #0-937175-75-7    A definitive source of information for the automounter under SunOS.   7.6: RFCs  There are no automounter RFCs.  8.0 Supportability   8.0: Supportability  SunService is not responsible for the initial configuration of your automount environment. In addition, SunService can not diagnose your NFS performance problems, or suggest NFS tuning guidelines.  We can help resolve problems where automount is not behaving correctly, but in such cases the contact must be a system administrator who has a good understanding of the automount environment.  9.0 Additional Support   9.0: Additional Support  For initial configuration, or NFS performance tuning guidelines, please contact your local SunService office for possible consulting offerings. Sun's Customer Relations organization can put you in touch with your local SunIntegration or Sales office. You can reach Customer Relations at 800-821-4643.  PATCH ID: n/a PRODUCT AREA: Gen. Network PRODUCT: Automounter SUNOS RELEASE: any UNBUNDLED RELEASE: n/a HARDWARE: any 
# # Internet host table # 127.0.0.1   localhost               loghost 10.0.0.101  acadie.internal         acadie 10.0.0.110  acadie-hme0 10.0.0.111  acadie-hme1 10.0.0.112  acadie-hme2 
10.0.0.0        255.255.255.0 
acadie netmask + broadcast + up \ group mofo \ addif acadie-hme0 netmask + broadcast + \ deprecated -failover up 
acadie-hme1 netmask + broadcast + \ group mofo \ deprecated -failover standby up 
acadie-hme2 netmask + broadcast + \ group mofo \ deprecated -failover standby up 
acadie# ifconfig hme0 hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2         inet 10.0.0.101 netmask ffffff00 broadcast 10.0.0.255         ether 8:0:20:c5:10:15 
acadie# ifconfig hme0 group mofo acadie# ifconfig hme0 addif 10.0.0.110 netmask 255.255.255.0 \     broadcast 10.0.0.255 -failover deprecated up 
acadie# ifconfig hme1 plumb 10.0.0.111 netmask 255.255.255.0 \     broadcast 10.0.0.255 group mofo deprecated -failover standby up acadie# ifconfig hme2 plumb 10.0.0.112 netmask 255.255.255.0 \     broadcast 10.0.0.255 group mofo deprecated -failover standby up 
acadie# ifconfig -a lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1         inet 127.0.0.1 netmask ff000000  hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2         inet 10.0.0.101 netmask ffffff00 broadcast 10.0.0.255         groupname mofo         ether 8:0:20:c5:10:15  hme0:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 2         inet 10.0.0.110 netmask ffffff00 broadcast 10.0.0.255 hme1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER,STANDBY,INACTIVE> mtu 1500 index 3         inet 10.0.0.111 netmask ffffff00 broadcast 10.0.0.255         groupname mofo         ether 8:0:20:c5:c0:53  hme2: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER,STANDBY,INACTIVE> mtu 1500 index 4         inet 10.0.0.112 netmask ffffff00 broadcast 10.0.0.255         groupname mofo         ether 0:60:5b:e:2:dd  

Command	Description
ci	Check in RCS revisions
co	Check out RCS revisions
ident	Identify files
merge	Three-way file merge
rcs	Change RCS file attributes
rcsclean	Clean up working files
rcsdiff	Compare RCS revisions
rcsmerge	Merge RCS revisions
rlog	Print log messages and other info on RCS files

Command	Basic Operation
ci	Creating an archive file
co	Getting a working file for reading
co -l	Getting a working file for modification
rcsdiff	Comparing a working file to its RCS file
ci	Adding a working file to an RCS file
rcs -u plus rm	Discarding a working file
rlog	Viewing the history of an RCS file
rcsclean	Cleaning up a source directory

Parameter	Description
`nfract`	The percentage of dirty pages in the buffer cache required to activate the `bdflush` task
`ndirty`	The maximum number of dirty pages in the buffer cache to write to disk in each `bdflush` execution
`reserved1`	Reserved for future use
`reserved2`	Reserved for future
`interval`	The number of jiffies (10ms periods) to delay between `bdflush` iterations
`age_buffer`	The time for a normal buffer to age before it is considered for flushing back to disk
`nfract_sync`	The percentage of dirty pages in the buffer cache required to cause the tasks which are writing pages of memory to begin writing those pages to disk instead
`nfract_stop_bdflush`	The percentage of dirty pages in buffer cache required to allow `bdflush` to return to idle state
`reserved3`	Reserved for future use

Parameter	Description
`min`	The minimum amount of memory to reserve for pagecache use.
`borrow`	The percentage of pagecache pages `kswapd` uses to balance the reclaiming of pagecache pages and process memory.
`max`	If more memory than this percentage is used by pagecache, `kswapd` only evicts pages from the pagecache. Once the amount of memory in pagecache is below this threshold, `kswapd` begins moving process pages to swap again.

Network Database	Local Files	NIS+ Tables	NIS Maps
hosts	/etc/inet/hosts	hosts.ord_dir	hosts.byaddr hosts.byname
netmasks	/etc/inet/netmasks	netmasks.ord_dir	netmasks.byaddr
ethers	/etc/ethers	ethers.ord_dir	ethers.byname ethers.byaddr
bootparams	/etc/bootparams	bootparams.ord_dir	bootparams
protocols	/etc/inet/protocols	protocols.ord_dir	protocols.byname protocols.bynumber
services	/etc/inet/services	services.ord_dir	services.byname
networks	/etc/inet/networks	networks.ord_dir	networks.byaddr networks.byname

`c0`	This device is attached to controller #0. On a SPARCstation this is usually the on-board SCSI or IDE controller. If this is a PC it usually refers to the first IDE controller on the motherboard.
`t2`	The device is target #2 - (i.e. the second device on this controller.) On a SCSI controller this is the SCSI target ID and is usually set via a switch on any external enclosure or by jumpers on the disk itself. On an IDE controller target #2 refers to the second IDE disk. With IDE this is generally determined by the device's position on the IDE cable.
`d0`	The device is Logical Unit / "LUN" #0 (the first) on this target. Under SCSI a single target can support up-to eight devices. This is rarely seen in practice, but some hardware raid controllers use LUNs.
`s7`	Slice or Partition number 7. Under Solaris, this relates to the partition number as set when using the `format` command.

Option #	Top Level Part #	Manufacturing Part #	Description	Substitute Part #
X1032A	595-4258	501-5656	Single-Ended Ultra/Wide SCSI/FastEthernet (SunSwift PCI)	501-2741
X2222A	595-5624	501-5727	Dual Ultra-2 SCSI/Dual FastEthernet PCI Adapter	n/a
X5010A	595-5377	375-0097	Single-Channel Single-Ended Ultra/Wide SCSI (PCI)	n/a
X6540A	595-4399	375-0005	Dual Single-Ended Ultra/Wide SCSI (PCI)	n/a
X6541A	595-4414	375-0006	Dual Differential Ultra/Wide SCSI (PCI)	n/a

KEY	DESCRIPTION
0	NO SENSE There is no specific sense key information to be reported for the designated logical unit. This would be the case for a successful command or a command that received CHECK CONDITION or COMMAND TERMINATED status because one of the filemark, EOM, or ILI bits is set to one.
1	RECOVERED DATA The last command completed successfully with some recovery action performed by the target. Details may be determined by examining the additional sense bytes and the information field.
2	NOT READY The logical unit addressed cannot be accessed. Operator intervention may be required to correct this condition.
3	MEDIUM ERROR The command terminated with a non-recovered error condition that was probably caused by a flaw in the medium or an error in the recorded data. This sense key may also be returned if the target is unable to distinguish between a flaw in the medium and a specific hardware failure (sense key 4).
4	HARDWARE ERROR The target detected a non-recoverable hardware failure while performing the command or during self test.
5	ILLEGAL REQUEST There was an illegal parameter in the command descriptor block or in the additional parameters supplied as data for some commands. If the target detects an invalid parameter in the command descriptor block, then it shall terminate the command without altering the medium. If the target detects an invalid parameter in the additional parameters supplied as data, then the target may have already altered the medium. This sense key may also indicate that an invalid IDENTIFY message was received.
6	UNIT ATTENTION The removable medium may have been changed or the target has been reset.
7	DATA PROTECT A command that reads or writes the medium was attempted on a block that is protected from this operation.
8	BLANK CHECK A write-once device or a sequential-access device encountered blank medium or format-defined end-of-data indication while reading or a write-once device encountered.
9	Vendor Specific This key is available for reporting vendor specific conditions.
a	COPY ABORTED A COPY, COMPARE, or COPY AND VERIFY command was aborted due to an error condition on the source device, the destination device, or both.
b	ABORTED COMMAND The target aborted the command. The initiator may be able to recover by trying the command again.
c	HARDWARE ERROR The target detected a non-recoverable hardware failure while performing the command or during self test.
d	VOLUME OVERFLOW A buffered peripheral device has reached the end-of-partition and data may remain in the buffer that has not been written to the medium.
e	MISCOMPARE The source data did not match the data read from the medium.
f	Reserved

Unix Tech Tips & Tricks

Small tutorial on SCCS

Small tutorial on SCCS

The Basics

Setup

Usage

Version info in the source code

Basic Source Control Using RCS

Applying RCS and SCCS

From Source Control to Project Control

Basic Source Control Using RCS

Understanding Virtual Memory -Linux

Understanding Virtual Memory

by Norm Murray and Neil Horman

Introduction

Definitions

What Comprises a VM

MMU

Zoned Buddy Allocator

Slab Allocator

Kernel Threads

The Life of a Page

Tuning the VM

bdflush

dcache_priority

hugetlb_pool

inactive_clean_percent

kswapd

max_map_count

max-readahead

min-readahead

overcommit_memory

overcommit_ratio

pagecache

page-cluster

Example Scenarios

File (IMAP, Web, etc.) Server

General Compute Server With Many Active Users

Non interactive (Batch) Computing Server

Further Reading

Cool Unix Commands

Cool Commands

HOWTO: Mirrored root disk on Solaris

Active FTP vs. Passive FTP, a Definitive Explanation

Configuring TCP/IP on Solaris - Overview of the Booting Processes

Configuring TCP/IP on Solaris - Network Configuration Procedures

Configuring TCP/IP on Solaris - Network Databases and nsswitch.conf File

Networking -- Solaris

Removing Invalid Disk Device Files (/dev/dsk and /dev/rdsk)

Understanding Disk Device Files (i.e. breaking down c0t2d0s7)

Adding SCSI Host Adapter (X6541A) into a Blade 100/150

Solstice DiskSuite - (Solaris 2.5.1 - Solaris 8)

Solaris Volume Manager - (Solaris 9)

Using NFS - (Solaris)

Diagnostic Command - (Sun Solaris)

Using Package Manager on Solaris

Configuring Power Management (Sun Blades Only)

Configuring Telnet / FTP to login as root (Solaris)

Booting Options and Using EEPROM

I/O Bottleneck - Trouble shooting

What does 100 percent busy mean?

Linux Memory Management

Contents

Overview of memory management

The mysterious 880 MB limit on x86

The difference among VIRT, RES, and SHR in top output

The difference between buffers and cache

Swappiness (2.6 kernels)

Autoregulation

INFO ON Promiscuous mode

Veritas volume manager documentation

Veritas volume manager documentation

Changing TimeZone to IST

SunService Tip Sheet: Network Security

SunService Tip Sheet: Network Security

SunService Tip Sheet: Sun NFS

SunService Tip Sheet: Sun NFS

SunService Tip Sheet: Sun Automounter

SunService Tip Sheet: Sun Automounter

Network failover using Solaris multipathing - in.mapthd