Troubleshooting
| When attempting to mount volumes from another computer, you might encounter filefork issues, the insecurity of NFS mounts, how Mac OS X reacts to the loss of a connection, more than one mounting of the same volume, and security issues related to Fast User Switching. You will also learn some tips for resolving browsing and mounting issues. Using Forked Files Over AFPThe Hierarchical File System Plus, HFS Plus, supports forked files, but other file systems, such as UFS, do not. When copying files between local volumes, Mac-specific utilities handle forks correctly, as do command-line utilities such as cp and mv, but only on Mac OS X systems. (Apple engineered such command-line utilities to handle resource forks properly.) The Windows graphical user interface does not support resource forks as well. A similar issue exists with file-sharing services. Only AFP supports forked files; NFS, SMB, and FTP do not. AFP was designed to handle forked files. When a forked file is written on a Mac OS X computer over AFP to a volume on a server, the File Manager on the Mac OS X computer treats the AFP mount point as if it were an HFS Plus file system. That is, it keeps the forked file intact. AFP also preserves the intact forked file as it is copied. Once the forked file is received on the server computer, the server's File Manager preserves the forked file if the volume is HFS Plus, or splits the file into two flat files if the volume is a flat-file system, such as UFS.  Using Forked Files Over NFSNFS, SMB, and FTP were not designed to handle forked files. The example shown in the following figure illustrates what happens when you copy a forked file over NFS. (This example shows NFS but applies to other non-AFP file systems as well.)  When you write a forked file on a Mac OS X computer over NFS to a volume on a server, the File Manager on the Mac OS X computer treats the NFS mount point as if it were a flat-file system. That is, it splits the file into two flat files. Because NFS on the server writes two separate files, the File Manager on the server computer stores the data as two flat files, regardless of the volume's file-system type. When a forked file is stored as two flat files on an HFS Plus file system over NFS, the file looks like a normal file when viewed from Mac OS X, but not when viewed from the server. Mac OS X graphical user interface applications executing on the Mac OS X computer expect forked files on an NFS volume to be stored as two flat files, because the File Manager on the Mac OS X computer treats the NFS mount point as if it were a flat-file system. Applications executing on the server, however, expect files on an HFS Plus file system to be intact. For the same reasons, when a forked file is created locally on an HFS Plus file system on the server and the volume is mounted on Mac OS X over NFS, the file looks normal when viewed from the server but not when viewed from Mac OS X. Understanding NFS SecurityNFS is inherently less secure than the other protocols because it does not authenticate users. The NFS server compares the IP address of your computer only with the list of computers that are authorized to mount the volume. The only time it does this comparison is when you mount the volume. Anyone with a packet sniffer can pretend to be an authorized client. NFS was developed when only trusted people could create an account; in a few places, this assumption is still true, such as in small, standalone research networks. In addition, NFS assumes that the user database on the client computer is exactly the same as the one on the server. If your user ID is 503 on your client computer, the NFS server believes that you are user 503 on the server. Potentially, this allows a client administrator to steal another user's identity on the server. All he would have to do is create a new user on his computer, and then change the user ID in his local NetInfo database. This is a tremendous security issue when root is enabled. NFS has some options that help administrators work around this problem. An NFS server administrator can:
Note Know the security policy on NFS servers that you mount. If you believe that a server is insecure, caution users against storing sensitive documents there. If users need only to download from the server, you can mount it as read-only. Disconnecting When Volumes Are MountedSometimes your computer may lose its connection to a server due to circumstances beyond your control. If you lose your network connection while you have volumes mounted, or if a server from which you have mounted becomes unavailable, Mac OS X will display an error message asking whether to disconnect from servers whose volumes you have mounted. The following figure shows the dialogs that appear when an AFP, SMB, or NFS share has been disconnected abruptly, whether from a network disconnection or a service shutdown. The dialogs with the thin bar across the top are called Inspector windows and appear over any windows. The larger dialogs with a thicker bar across the top may not appear over all windows, so anyone using the computer at that time may not be alerted to the shutting down of a server. The three dialogs with the red octagon appear when the service has stopped abruptly but the network connection to the server is still valid.  Mac OS X version 10.4 will reconnect automatically if a connection is lost. This information (the automount daemon and the kernel write messages about lost connections) is output to the system.log file. Here is an example of a mount that was successful, followed by the physical network connection being lost, and then a reconnect minutes later. The volume reconnects automatically and attempts to reconnect every 10 seconds:
The log is snipped here due to its length. A reconnect is attempted every 10 seconds between these entries.
Eventually, automount unmounts the volumes, and they no longer appear in the Network browser, in the Sidebar or desktop, or in the output of the mount command. Note If you reestablish your link to the network or the server becomes available again, the spinning ball icon might appear when you attempt to use the Finder. Relaunch the Finder to get rid of the icon. Working With Multiple Mounts and Multiple UsersNormally, all mounted volumes unmount when a user logs out. However, if Fast User Switching is enabled and more than one user is logged in, mounted volumes are not unmounted automatically when a user logs out. The volumes remain mounted and are accessible to all users logged in to the computer. The following output shows several volumes mounted by several users who have logged in using Fast User Switching. (The table before the output should help you decipher the text.) Mount Points
AmieiBook:~ hadmin$ mount /dev/disk0s3 on / (local, journaled) devfs on /dev (local) fdesc on /dev (union) volfs on /.vol automount nsl [117] on /Network (automounted) automount fstab [136] on /automount/Servers (automounted) automount static [136] on /automount/static (automounted) afp_005An80ZHyoM001Eic06SdO01.2c000006 on /Volumes/Approved_Files (nodev, nosuid, mounted by hadmin) afp_005An80ZHyoM001Eic06SdO01.2c000007 on /Volumes/Approved_Files1 (nodev, nosuid, mounted by amie) afp_005An80ZHyoM001Eic06SdO02.2c000008 on /Volumes/Groups (nodev, nosuid, mounted by amie) afp_005An80ZHyoM001Eic06SdO01.2c000009 on /Volumes/Approved_Files2 (nodev, nosuid, mounted by dakota) afp_005An80ZHyoM001Eic06SdO02.2c00000a on /Volumes/Users (nodev, nosuid, mounted by dakota)If a disconnect happens, a collective inspector dialog appears after a few minutes, as shown in the following figure, informing the logged-in user that several mounts have become available and offering to disconnect the orphaned mount points. However, a successful rejoining of the server or the Mac OS X computer to the network will result in a reconnect. Troubleshooting BrowsingIf a computer does not appear in the Network browse list on your computers, try the following:
Troubleshooting Mount IssuesWhen attempts to mount a volume fail, several other dialogs commonly appear.  If you can browse a computer but cannot connect, try the following:
Recognizing Connection ErrorsSometimes when the Finder cannot connect to a server, it provides an error message. If the Finder detects an error before it attempts to mount, the message will not contain an error code. Two causes of this are nonexistent computers and bad authentication information, as shown in the following figure.  If you try to mount a volume that is not being shared, you will get an error message with error code 36. You might see some of the following error messages when mounting from the command line:
You can look up error codes on Mac OS X or Mac OS X Server by viewing the file/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Headers/MacErrors.h. Sometimes processes write error messages to the system log. Look for the following process names in Console. The error might be related to file sharing.
Checking Server AvailabilityIf users cannot connect to a server, you should check access to the server itself. You can use Port Scan in Network Utility to scan for open network ports on the server. There are several command-line utilities you can use to verify that SMB or NFS service is available on a server. SMBTo see what an SMB server is sharing, type smbclient L hostname NThe results should look something like this: Domain=[RECOVERY] OS=[Unix] Server=[Samba 3.0.10] Sharename Type Comment ________ ____ ______ Groups Disk macosx Public Disk macosx Users Disk macosx IPC$ IPC IPC Service (Mac OS X) ADMIN$ IPC IPC Service (Mac OS X) Anonymous login successful Domain=[RECOVERY] OS=[Unix] Server=[Samba 3.0.10] Server Comment ________ ______ MYMAINSERVER Mac OS X Workgroup Master _________ ______ RECOVERY Testing whether you can authenticate with a specific user name and password uses the format smbclient //hostname/share U user%password where password is your password on the SMB server. This should give you an smb: \> prompt. (Type exit to exit the prompt.) If you don't get the prompt, there's a problem with either the user name or password. To check that the NetBIOS name maps to a particular IP address, type nmblookup U IPaddr hostname where IPaddr is the IP address and hostname is the hostname of the SMB server. It should respond with the same IP address and hostname. NFSTo query the state of an NFS server, you can use rpcinfo and showmount. To see whether the NFS processes on the server have registered with portmap, type rpcinfo p servername where servername is the name of the NFS server. The output should show nfs and mountd. For example: rpcinfo p mainserver program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 1020 status 100024 1 tcp 1017 status 100021 0 udp 1008 nlockmgr 100021 1 udp 1008 nlockmgr 100021 3 udp 1008 nlockmgr 100021 4 udp 1008 nlockmgr 100021 0 tcp 1016 nlockmgr 100021 1 tcp 1016 nlockmgr 100021 3 tcp 1016 nlockmgr 100021 4 tcp 1016 nlockmgr 100005 1 udp 989 mountd 100005 3 udp 989 mountd 100005 1 tcp 1014 mountd 100005 3 tcp 1014 mountd 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs To see what volumes are being exported (shared) by the server and who is allowed to mount those volumes, use showmount e servername. For example: showmount e mainserver and showmount e mainserver.pretendco.com To see which other computers have mounted NFS volumes from the server, use showmount servername. For example: showmount mainserver and showmount mainserver.pretendco.com |
/lookupd"[380]: exited abnormally: Hangup Oct 24 16:48:25 instructor configd[32]: posting notification com.apple.system.config 
EAN: 2147483647
Pages: 258