When you try to access a file share, errors might occur because of user profile problems.
User profiles might 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 might be unable to use iSeries™ NetServer™ if they attempt to connect to the i5/OS operating system with an incorrect password too many times. If this occurs, then the system 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 the i5/OS operating system or iSeries Access for Windows®, but it does stop the user profile from accessing iSeries NetServer.
Management Central has a function to monitor messages from the QSYSOPR message queue. An administrator can use this function to be alerted to profiles being disabled for iSeries NetServer use. The administrator can 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 or client the QZLSFILE job is servicing. A QZLSFILET job might have numerous messages in the job log because it services multiple 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 names, logon types, and server sessions is displayed.
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.
As of V5R4, iSeries NetServer by default services file shares in a multithreaded 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.
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. 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. Because 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.
To prevent "access denied" type errors, the recommended solution is to avoid starting the QZLSFILET job in the QSERVER subsystem (or other user subsystems). This might involve configuring user subsystems in iSeries Navigator so that some clients run threaded and others run nonthreaded. Use the following command to remove the prestart job entry for QZLSFILET from the QSERVER subsystem:
RMVPJE SBSD(QSYS/QSERVER) PGM(QSYS/QZLSFILET)If a prestart job entry is to be removed from a different subsystem, then that subsystem needs to be specified instead of QSERVER along with its correct library (the program remains the same).
Programs created with the activation group new ACTGRP(*NEW) option will cause multithreaded jobs to end when the program returns. Therefore, when clients might run in a threaded environment (QZLSFILET job), a program created with ACTGRP(*NEW) should not be registered for exit point QIBM_QPWFS_FILE_SERV.
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.