Troubleshoot iSeries NetServer user profile connections

When you are trying to access a file share, an error code may appear for any of the following reasons:

User profiles may not be authorized to a particular shared directory. If this occurs, ensure that the user can access the directory by using i5/OS control language (CL) commands, such as Work with Object Links (WRKLNK).

Users may be unable to use iSeries NetServer™ if they attempt to connect to iSeries with an incorrect password too many times. If this occurs, then iSeries sends a message (CPIB682) to the QSYSOPR message queue. This message indicates that the user profile has been disabled for iSeries NetServer access. This does not disable the user profile for iSeries or iSeries Access for Windows, but it does stop the user profile from accessing iSeries NetServer.

In V5R1, Management Central has a function to monitor messages from QSYSOPR. An administrator could use this function to be alerted to profiles being disabled for iSeries NetServer use. Also in V5R1, the administrator could use iSeries Navigator to periodically look at a list of disabled users and re-enable users from the panel. To find all disabled user profiles, right-click iSeries NetServer and select Disabled Profiles.

Clients should connect to iSeries NetServer by using their valid user profiles and not the guest user profile. The QZLSFILET or QZLSFILE job might be in the QSERVER subsystem for each active client [user] that connects to an iSeries NetServer [file share]. However, QZLSFILET and QZLSFILE jobs can run in another subsystem if the user has configured other subsystems to run iSeries NetServer jobs. Message CPIAD12 in the job log indicates which user/client the QZLSFILE job is servicing (a QZLSFILET job may have numerous messages in the job log because it services mulitple clients). From iSeries Navigator under Network > Servers > TCP/IP, double-click iSeries NetServer and then click Sessions. A listing of users and their respective workstation name, logon type, and server session is displayed. End of change

A client that is running threaded will receive "access denied" type errors when trying to access a non threadsafe file system (such as QDLS or QNetWare). The client will also receive errors when attempting to map a drive to a non threadsafe file system when the client session is running threaded. For a listing of file systems that are not threadsafe, see File system considerations for multithreaded programming in the Multithreaded applications topic. End of change

As of V5R4, iSeries NetServer by default services file shares in a multi-threaded job. The threaded activity for all sessions in a subsystem runs in the pool of threads in the QZLSFILET job for that subsystem. Non threaded client activity is still run in QZLSFILE jobs. End of change

A QZLSFILE job in the correct subsystem is still required to launch a threaded session. Whether a client can run threaded is determined when it first maps a drive to the integrated file system (IFS). The first phase of mapping the first drive for a client runs in a QZLSFILE job. If the session can run threaded, the session is transferred into the single QZLSFILET job in the subsystem. If the file system is not threadsafe, or the ADDEXITPGM THDSAFE() option for the QIBM_QPWFS_FILE_SERV exit point is specified as *UNKNOWN or *NO, or QZLSFILET is not present in the subsystem, the client runs in a QZLSFILE job for this session. The QZLSFILE job log records when a client starts. When a client ends the session, the QZLSFILE job returns to prestart wait status and its job log is cleared. When a client starts a session with a QZLSFILET job, message CPIAD12 is written into its job log. Since the QZLSFILET job is used by multiple client sessions, the session end message, CPIAD13, is written to its job log when a user/client session is ended. These messages will accumulate in the job log. End of change

To prevent "access denied" type errors, the recommended solution is to not have the QZLSFILET job started in the QSERVER subsystem (or other user subsystems) . This may involve configuring user subsystems in iSeries Navigator so that some clients run threaded and others non-threaded. Use the following command to remove the prestart job entry for QZLSFILET from the QSERVER subsystem.

If a prestart job entry is to be removed from a different subsystem, then that subsystem would need to be specified instead of QSERVER along with its correct library (the program would remain the same). End of change

Active print users will have a job in QUSRWRK that connects to iSeries NetServer. A message in the job log indicates to which user the QNPSERVS job belongs.