This error is remote file sharing (RFS) specific. It occurs when users try to advertise, unadvertise, mount, or unmount remote resources while the machine has not properly started a network connect.
The symbolic name for this error is ENONET, errno=64.
This message appears in a pop-up dialog box whenever you ask mailtool(1) to access messages after another mail reader has modified your inbox. A request follows: Please Quit this Mail Tool.
Click continue to close the dialog box, then exit mailtool(1). If you continue trying to read mail, messages deleted by the other mail reader will never appear, and mailtool(1) will fail to see any new messages.
This message comes from mail(1) or mailx(1) whenever it detects messages with a different content length than advertised. The mail(1) program tells you which message might be truncated or might have another message concatenated to it.
Two common causes of content length mismatches are the simultaneous use of different mail readers (such as mail(1) and mailtool(1)), or the use of a mail reading program (or an editor) that does not update the content-length field after altering a message.
The mailx(1) program can usually recover from this error and delineate mail message boundaries correctly. Pay close attention to the message that might be truncated or combined with another message, and to all messages after that one. If a mail file becomes hopelessly corrupted, run it through a text editor to eliminate all Content-Length lines, and ensure that each message has a From (no colon) line for each message, preceded by a blank line.
An attempt was made to send a message with mailtool(1) from a directory where the user does not have write permission, and the user's home directory is currently unavailable.
Change to another directory and start mailtool(1) again, or use chmod(1) to change permissions for the directory (if possible).
When a user runs mailtool(1) on a remote machine, setting the DISPLAY environment back to the local machine, this message might appear inside a dialog box window. The message also indicates that the Classing Engine must be installed to use Attachments. This problem occurs because rlogin(1) does not propagate the user's environment.
Exit mailtool(1) and set your OPENWINHOME environment variable to /usr/openwin. Then run mailtool(1) again. The error message does not appear, and you can now use Attachments.
Classing Engine is a new name for Tool Talk. Earlier versions of mailtool(1) said Tool Talk: TT_ERR_NOMP instead of Classing Engine.
When the Windows GUI (fwpolicy) is started in Firewall-1 3.0 and the login process is initiated, the error message window pops up displaying this message.
The Firewall-1 GUI packages SUNWfwgui and SUNWfweui were installed in the incorrect order. First, remove the packages using pkgrm(1M). Next, install the SUNWfwgui and, then, the SUNWfweui in that order to resolve the error message.
A swap file was created with the following command:
# mkfile -nv 50m /ab/swap_50mb
# swap -a /ab/swap_50mb
/ab/swap_50mb may contain holes - can't swap on it. /ab/swap_50mb: Error 0
Starting with the Solaris 2.0 release, -n works only when the file is to be used by the NFS system. Local swap files cannot be created with the -n option.
This error has to do with mbuf allocation.
This message can occur when printing large files on a SPARCprinterTM attached to a SPARCstation 2.
Replace the SPARCstation 2 CPU with one that is at the most recent dash level.
An application uses up more and more memory, until all swap space is exhausted.
Third-party software can help identify memory leaks in their applications. If you suspect that you have a memory leak, you can use sar(1) to check on the Kernel Memory Allocation (KMA). Any driver or module that uses KMA resources, but does not specifically return the resources before it exits, can create a memory leak.
For more information on memory leaks, see the section on monitoring system activity in the System Administration Guide, Volume 2. If you are using AnswerBook online documentation, "displaying disk usage" is a good search string. Also, see the section on system resource problems in the NIS+ and FNS Administration Guide.
A message sent on a transport provider was larger than the internal message buffer or some other network limit.
The symbolic name for this error is EMSGSIZE, errno=97.
While trying to mount a file system, the mount(1M) command received a "Device busy" (EBUSY) error code. Several possible reasons are: this /dev/dsk file system is already mounted on a different directory, the busy path name is the working directory of an active process, or the system has exceeded its maximum number of mount points (unlikely).
Run /etc/mount to see if the file system is already mounted. If not, check to see if any shells are active in the busy directory (did the user switch to the directory by using cd(1)?), or if any processes in the ps(1) listing are active in that directory. If the reason for the error message is not obvious, try using a different directory for the mount point.
An existing server did not respond to an NFS mount request, so after retrying a number of times (default 1000), the mount(1M) command has ceased. Nonexistent servers or bad mount points produce different messages.
If the RPC: Program not registered message precedes this one, the requested mount server probably did not share (export) any file systems, so it has no NFS daemons running. Have the superuser on the mount server run share(1M) on the file system, then run /etc/init.d/nfs.server start to begin NFS service.
If the requested mount server is down or slow to respond, check whether the machine needs repair or rebooting.
Someone tried to mount a file system onto the specified directory, but there is no such directory.
If this is the directory name you want, run mkdir(1) to create this directory as a mount point.
The system was unable to mount the file system that was specified because the super block indicates that the file system might be corrupted. This is not an impediment for read-only mounts.
If you do not need to write on this file system, run mount(1M) on it using the -o ro option. Otherwise, do as one of the message continuation lines suggests and run fsck(1M) to correct the file system state and update the super-block.
This error occurs when users try to access remote resources that are not directly accessible.
The symbolic name for this error is EMULTIHOP, errno=74.