Troubleshooting user profile connections

When you try to access a file share, errors might occur because of user profile problems.

• Lack of authorization

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

• Attempting to connect with incorrect password

  Users might be unable to use IBM® i NetServer if they attempt to connect 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 IBM i NetServer access. This does not disable the user profile for IBM i or IBM i Access for Windows, but it does stop the user profile from accessing IBM i NetServer.

  Note: 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 IBM i NetServer use. The administrator can use System i® Navigator to periodically look at a list of disabled users and re-enable users from the window. To find all disabled user profiles, right-click IBM i NetServer and select Disabled Profiles.
• QZLSFILE and QZLSFILET jobs are not configured for a subsystem

  Clients should connect to IBM i 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 IBM i NetServer file share. However, QZLSFILET and QZLSFILE jobs can run in another subsystem if the user has configured other subsystems to run IBM i 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 System i Navigator, under Network > Servers > TCP/IP, double-click IBM i NetServer and then click Sessions. A listing of users and their respective workstation names, logon types, and server sessions is displayed.

• Trying to access a non threadsafe file system while running threaded

  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, IBM i 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 System i 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

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