File Access Denied

Problem: Attempts to access a file on the server fail with an access denied error. A typical access denied error looks like:

File error 37,07 on @condor:/usr2/bsmith/fio_seq

The 37, 07 error code (ANSI 85 standard error code) indicates that the user does not have sufficient permissions to access the file. If your application uses one of the alternate sets of file status codes, your error code will differ. See the ACUCOBOL-GT Runtime Manual for more information.

Access denied errors occur because a file's permissions, or the permissions of a directory in which the file resides, prohibit access. Finding and correcting access denied errors requires familiarity with AcuServer access security and Windows NT/2000 or UNIX file security. You may need access to administrator or root privileges. Work with your site's AcuServer system administrator to resolve the problem.

AcuServer adds complexity to finding access denied errors, because AcuServer handles requests with a user ID (user name) designated in the server access file (AcuAccess). The user name designated may not be the user name that you expect. Therefore, finding and resolving access denied errors can involve inspecting two components of the system: file protections and the AcuServer server access file. AcuServer also adds complexity when implementing native system security, because the server impersonates the connecting client. See Unexpected User Name for more information.

File permissions diagnostics are used to verify that the ownerships and permissions on the file and directories do, in fact, allow access to the user ID that AcuServer is using (or the user name that you assume that AcuServer is using).

The AcuServer user name diagnostics are used to determine the actual user name that AcuServer is using when the access denied error occurs. Step-by-step diagnostic procedures follow.

Whether you first verify the user ID or first check the file permissions, is up to you. If you're familiar with file security, you may find it faster to check the file permissions first, under the assumption that AcuServer is using the user ID that you expect. Then, if necessary, you can verify the user ID, followed by repeating the file permissions inspection if the actual user name differs from the assumed name.

The steps below break the diagnostic process into three activities:

1. Getting the full path of the file generating the error
2. Checking the file permissions (UNIX, Windows)
3. Determining the user ID used by AcuServer

See The Server Access File to review the structure and function of the server access file. See AcuServer Connection Logic to review the procedure used by AcuServer to get the requester's user ID. See Ownerships and Permissions for a brief description of file permissions.

1. Getting the file name

   Get the name and path of the file that produces the access denied error.

   Most applications will report the full path and name of the file in the standard error output. If your application doesn't, run your application again with the -x runtime option:

   runcbl -x your-usual-options program-name

   If the -x option doesn't produce the full name and path, run the application in the debugger with FILE TRACE enabled and examine the log file for the first occurrence of an access error. The file name that precedes the error is the file generating the error.

   To run the debugger enter:

   runcbl -dle error-file your-usual-options program-name 

   where:

   -d turns on the debugger, -l causes the contents of the runtime configuration file to be included in the error output, and -e causes file trace and error output to be placed in error-file.

   After starting your program, you will be at the debugger screen. Turn on file tracing by entering

   tf

   FILE TRACE will be echoed to the screen. To start program execution, enter:

   g

   Allow the program to run until you encounter the error condition, and then exit. Your log file will contain the error information, all COBOL configuration file variables that have been set, and a record of every OPEN, READ, and WRITE.

   Examine the log file and find the error output for the access denied error. The file name that precedes the error is the file generating the error. Note the full path of the file and retain the log file for future reference.

2. Checking permissions
   1. Checking UNIX permissions If you are using a UNIX server, verify that the file and directory permissions grant access to the user name:
      1. Log on to the server with the user name used (assumed to be used) by AcuServer. If that's not possible (you don't know the password or the login attempt fails), skip to step 3.
      2. After logging onto the server, perform an ls -l on the file using the full path (beginning with "/"). For example:

         ls -l /usr2/bsmith/fio_seq

         If the ls -l fails with a cannot access directory (or similar) error, the permissions on one or more of the directories are too restrictive. To access a directory, the directory must allow you EXECUTE permissions. Adjust the permissions or move the file to a directory that will allow access. If you are not the owner of the directories, you will need to ask the owner, or someone with root privileges, for assistance.

         After adjusting the permissions, verify directory access to the file by performing an ls -l on the full path to the file. If the ls -l succeeds, the permissions set on the file are displayed. For example:

         -rw-r--r--  1 prod  general  4870  Aug 18 1993  
            /usr2/bsmith/fio_seq

         Evaluate the file's ownerships and permissions, including the group permissions, to determine if they allow the type of access required by the requesting application. Except as noted below, all files opened by AcuServer must allow READ and WRITE access. Under Sun OS with ACUCOBOL-GT Version 2.1.2 or later, files having READ only permissions may be opened INPUT.

         If the file's permissions need changing and the file is not owned by you, you will need to enlist the assistance of the owner of the file or someone with root privileges.

         Once the file and directories permit access, run the application again. If the program fails when attempting to access the same file and you have not yet confirmed the user name that AcuServer is using, perform the Confirming the user name diagnostics (below).

      3. If you can't log onto the server under the user name used by AcuServer, ask your UNIX system administrator to evaluate whether the file in question is accessible to the user name. If the file or directories do not allow access, ask the owner of the file, or the system administrator, to adjust the permissions to allow access.

         After the permissions have been adjusted, run the application again. If the program fails attempting to access the same file and you have not yet confirmed the user name that AcuServer is using, proceed to the next section. Otherwise, contact Customer Support.

   2. Checking Windows NT/Windows 2000/ 2003/2008 permissions

      If you are using a Windows NT, Windows 2000 to 2008 server, verify that the file and directory permissions grant access to the user name.

      1. Log on to the server with the user name used (assumed to be used) by AcuServer. If that's not possible (you don't know the password or the login attempt fails), skip to step 3.
      2. After logging onto the server, select the file or directory. Then select:

         File/Properties/Security/Permissions

         from the menus. If the permissions are too restrictive, adjust the permissions or move the file to a directory that will allow access.

         When AcuServer is running as a Windows service, it belongs to an implicit group called SYSTEM. Otherwise it should belong to the Administrators group. If you are using AcuServer system security, make sure that the SYSTEM and Administrators groups are added to your file permissions with Full Control. This step is not necessary if you are implementing Windows NT security.

         Under AcuServer system security, files created by AcuServer are owned by the administrators group and allow Full Control for SYSTEM and Administrator. Everyone is given the permissions specified by the third digit in the umask in the AcuAccess file.

         If you are not the owner of the directory or file, you will need to ask the owner, or someone with administrator privileges, for assistance.

         Once the file and directories permit access, run the application again. If the program fails when attempting to access the same file and you have not yet confirmed the user name that AcuServer is using, perform the Confirming the user name diagnostics (below).

      3. If you can't log onto the server under the user name used by AcuServer, ask your system administrator to evaluate whether the file in question is accessible to the user name. If the file or directories do not allow access, ask the owner of the file, or the system administrator, to adjust the permissions to allow access.

         After the permissions have been adjusted, run the application again. If the program fails attempting to access the same file and you have not yet confirmed the user name that AcuServer is using, proceed to the next section. Otherwise contact Customer Support.

3. Confirming the user name

   Confirm the user name that AcuServer is using when the access denied error occurs (see also sectino Unexpected User Name).

   Note that some procedures require root or administrator privileges. If you don't have these privileges, enlist the assistance of your AcuServer or system administrator.

   1. If there is any doubt about your client user name, confirm your client user name.

      On UNIX systems:

      Enter who am I at the UNIX prompt.

      On Windows systems:

      If a user is logged into a Windows NT/2000 workgroup or domain, AcuServer will use the user's log-in name. Otherwise, it uses the user name value that is set by the environment variable USERNAME. If USERNAME is not set, the runtime uses the value that is set by the environment variable USER. (The values of these variables are case-sensitive.) If neither of these environment variables is set, the runtime uses the literal string USER.

      To confirm the presence (or absence) of the USERNAME environment variable, enter SET at the command prompt. SET will display the values of all environment variables.

      COMSPEC=C:\COMMAND.COM
      PATH=C:\;C:\WINDOWS;C:\MOUSE;
      PROMPT=$P$G
      USERNAME=BERNIE

      If USERNAME is defined, the value of USERNAME is the name passed to AcuServer. Otherwise, the variable USER is checked. If USER is not set, then the literal string USER is passed.

   2. If acuserve is running with level 2, 3, 6, or 7 tracing enabled, all connections and disconnections are reported in the AcuServer log file. Inspect the log file and look for the last connection entry for your client machine name/client user name combination. The trace messages associated with that connection request will include the Local Username that AcuServer has assigned to that connection. Find the line that reports the mapping of the client user name to the local user name.

      acuserve: 06/13/94 12:43:44 - 
         Server version: 010000
         Client version: 010000
      acuserve: 06/13/94 12:43:44 - 
         AUTHORIZATION request from user:bernie
      >> client:starling, 
         PASSWORD-ATTEMPTS allowed:3
      >> Mapping user:bernie to local user:bsmith
      >> Socket:5, uid:205, gid:101
      >> Password is not required
      acuserve: adding   
         client:starling, user:bernie, 
         pid:18397, fid:57a28

      If the local user name is not the one you expect, consult with your AcuServer system administrator to verify that it is the correct user name. Your system administrator can make any necessary changes to the server access file.

   3. If acuserve is not running with tracing enabled, you can turn it on using the acuserve -config option. At the command line, type
      • acuserve -config
      • then set FILE_TRACE 2 (or 3, 6, or 7) at the prompt
      • then exit
      After tracing is turned on, run your application again and follow the procedure outlined in step 2, above.

      When you no longer want tracing enabled, type acuserve -config again, then type set FILE_TRACE 0 at the prompt.

runcbl -x your-usual-options program-name

runcbl -dle error-file your-usual-options program-name

tf

g