Chapter 30

Troubleshooting File Access Problems (Tasks)

This chapter provides information on resolving file access problems such as those related to incorrect permissions and search paths.

This is a list of troubleshooting topics in this chapter.

Users frequently experience problems, and call on a system administrator for help, because they cannot access a program, a file, or a directory that they could previously use. Whenever you encounter such a problem, investigate one of three areas:

The user's search path may have been changed, or the directories in the search path may not be in the proper order.
The file or directory may not have the proper permissions or ownership.
The configuration of a system accessed over the network may have changed.

This chapter briefly describes how to recognize problems in each of these three areas and suggests possible solutions.

Solving Problems With Search Paths (`Command not found`)

A message of Command not found indicates one of the following:

The command is not available on the system.
The command directory is not in the search path.

To fix a search path problem, you need to know the pathname of the directory where the command is stored.

If the wrong version of the command is found, a directory that has a command of the same name is in the search path. In this case, the proper directory may be later in the search path or may not be present at all.

You can display your current search path by using the echo $PATH command. For example:

$ echo $PATH 
/home/kryten/bin:/sbin:/usr/sbin:/usr/bin:/usr/dt:/usr/dist/exe

Use the which command to determine whether you are running the wrong version of the command. For example:

$ which acroread 
/usr/doctools/bin/acroread

Note - The which command looks in the .cshrc file for path information. The which command might give misleading results if you execute it from the Bourne or Korn shell and you have a .cshrc file than contains aliases for the which command. To ensure accurate results, use the which command in a C shell, or, in the Korn shell, use the whence command.

How to Diagnose and Correct Search Path Problems

Display the current search path to verify that the directory for the command is not in your path or that it isn't misspelled.
$ echo $PATH

Check the following:
- Is the search path correct?
- Is the search path listed before other search paths where another version of the command is found?
- Is the command in one of the search paths?
If the path needs correction, go to step 3. Otherwise, go to step 4.

Add the path to the appropriate file, as shown in this table.

Shell

File

Syntax

Notes

Bourne and Korn

$HOME/.profile

$ PATH=$HOME/bin:/sbin:/usr/local /bin ...

$ export PATH

A colon separates path names.

$HOME/.cshrc

$HOME/.login

hostname% set path=(~bin /sbin /usr/local/bin ...)

A blank space separates path names.

Activate the new path as follows:

Shell
File Where Path Is Located
Use this Command to Activate The Path

Bourne and Korn
.profile
$ . ./.profile

C
.cshrc
hostname% source .cshrc

.login
hostname% source .login

Verify the new path.
$ which command

Example--Diagnosing and Correcting Search Path Problems

This example shows that the mytool executable is not in any of the directories in the search path using the which command.

venus% mytool
mytool: Command not found
venus% which mytool
no mytool in /sbin /usr/sbin /usr/bin /etc /home/ignatz/bin  .
venus% echo $PATH
/sbin /usr/sbin /usr/bin /etc /home/ignatz/bin
venus% vi ~.cshrc
(Add appropriate command directory to the search path)
venus% source .cshrc
venus% mytool

If you cannot find a command, look at the man page for its directory path. For example, if you cannot find the lpsched command (the lp printer daemon), lpsched(1M) tells you the path is /usr/lib/lp/lpsched.

Solving File Access Problems

When users cannot access files or directories that they previously could access, the permissions or ownership of the files or directories probably has changed.

Changing File and Group Ownerships

Frequently, file and directory ownerships change because someone edited the files as superuser. When you create home directories for new users, be sure to make the user the owner of the dot (.) file in the home directory. When users do not own "." they cannot create files in their own home directory.

Access problems can also arise when the group ownership changes or when a group of which a user is a member is deleted from the /etc/group database.