NetServer for everyone – part 5

How to fix the most common problems

In this fifth article on NetServer for IBM i we try to address the most common problems that can occur and indicate possible solutions.

Sometimes accessing IBM i shared resources through NetServer causes annoying headaches.
On the one hand we have the server part (i.e. IBM i) with its technological evolution and the succession of operating systems (we have reached 7.5) and on the other a constellation of clients with an equal variety of versions of operating systems and services pack. All this exponentially multiplies the coexistence combinations of different clients and servers. To all this add the problems of configuring firewalls and/or routers in case the server is on a remote network compared to the client.

I think this series of articles can be useful and convenient to have a “cover” that summarizes all the information necessary for configuring NetServer server-side and client-side and an overview of the most frequent situations of connection problems. Both operating systems (server and client) are constantly evolving, so this mini-guide cannot be exhaustive, but I hope it can help you in many of the situations you will encounter in your daily activity.
Previous articles:

• configure the service
• share IFS resources
• manage NetServer from command line with NetTools
• access shared resources

Profile disabled for NetServer

Particular attention must be paid to the case in which the profile is disabled for the NetServer service. If a user exceeds the maximum number of login attempts (specified in the system value QMAXSIGN ) the profile is disabled for the NetServer service.

When a profile is disabled the message is sent CPIB682 to the message queue QSYSOPR

A profile in *ENABLED state for the operating system
may be in *DISABLED status for the NetServer service only

In the past it was possible to re-enable a profile for NetServer using the command CHGUSRPRF USRPRF(profile-name) . NetServer used the profile’s last modification date to determine if it had changed since it was disabled. If the modified date was more recent than the disabled date the profile was re-enabled for the NetServer.
This method in the presence of specific PTFs does not re-enable the user for the NetServer service. The PTFs for each release that disengage the CHGUSRPRF command to re-enable the profile for NetServer are: V5R4M0: MF55657 / V5R4M5: MF55658 / V6R1M0: MF55659 / V6R1M1: MF55660 / V7R1M0: MF55661 and in all releases since 7.2

Last possibility a little more drastic: by restarting the NetServer service all the disabled profiles are re-enabled.

To check which users are in disabled state for NetServer the SQL service can also help us USER_INFO :

select USER_DEFAULT_PASSWORD, AUTHORIZATION_NAME "User", TEXT_DESCRIPTION "Description", PREVIOUS_SIGNON "Last login 5250", SIGN_ON_ATTEMPTS_NOT_VALID "Collections not valid", STATUS "Status", PASSWORD_CHANGE_DATE "Date/Time mod.pwd", DAYS_UNTIL_PASSWORD_EXPIRES "password expiration days ", SET_PASSWORD_TO_EXPIRE "Pwd to expire.", HOME_DIRECTORY "Current Directory", NETSERVER_DISABLED from USER_INFO where NETSERVER_DISABLED = 'YES' order by AUTHORIZATION_NAME;

Problem accessing QDLS file system shared resources

Given that the QDLS file system should be used as little or not at all, you may still need to access some of its folders.
Most likely the same client may need to access both QDLS and other file system resources. This coexistence is not always easy.

The reason lies in the threadsafe nature of file systems. This is all explained in detail in the IBM document “ IBM i NetServer Threaded Request Support “.

Since V5R4 when a client accesses a shared NetServer resource the system by default tries to manage the resource in a multithreaded job ( QZLSFILET ), that is, a single job can satisfy the requests of many different clients.
So if, accessing the IBM i server, the first resource to be accessed belongs to a threadsafe file system, the client’s request is directed to the job QZLSFILET ; if from the same client a subsequent attempt is made to access a resource belonging to a non-threadsafe file system (e.g. the QDLS) the system responds with a generic error or a continuous request for access credentials. The problem is that the job QZLSFILET (multithreaded) cannot manage access to a non-threadsafe resource.
The problem (on the client side) can be bypassed by first accessing the non-threadsafe shared resource (i.e. the QDLS) and then accessing the other resources, so that the client’s request is routed to the job QZLSFILE .
If using QDLS file system shared resources in conjunction with root file system resources continually creates problems you may want to consider (though not recommended) disabling the multithreaded preboot job QZLSFILET . The IBM technical document “ Disabling and Re-Enabling the Use of the Threaded QZLSFILET NetServer Job ” (ref. 643625) explains how to disable the QZLSFILET job.

NetServer does not start

Starting the NetServer with the command STRTCPSVR *NETSVR even in case of failure to start the service you will not get an escape message from executing the command. It is necessary to check from Navigator for i that the service is active. Or check your message queue QSYSOPR that the correct start message is present. In case of failure instead you will find the message with code CPIB683 which can already give us a first indication of the problem.

Cold restart

After verifying the correct configuration of the service (cf first article to chap. “Configure NetServer”) you can try a cold restart of the service. For the various TCP services there is generally a documented procedure for a cold restart. Unlike a normal restart, a cold restart attempts to terminate and reset the state of the service as if it had not previously been started or as if it were immediately following an IPL. In the case of the NetServer service, the procedure is as follows:

1. CHGPJE SBSD(LIBL/QSERVER) PGM(QZLSFILE) STRJOBS(NO)
2. ENDPJ SBS(QSERVER) PGM(QZLSFILE) OPTION(*IMMED)
3. CALL QZLSENDS PARM(x'00000000')
4. CALL QZLSSTRS PARM('1' x'00000000')
   If the service starts successfully, run:
5. CHGPJE SBSD(LIBL/QSERVER) PGM(QZLSFILE) STRJOBS(YES)
6. STRPJ SBS(QSERVER) PGM(QZLSFILE)

Firewalls

The NetServer service uses TCP ports 137, 138 and 139 (NetBios) and 445 (CIFS). So if the server is on a remote network from the client protected by a firewall, you need to make sure that network traffic on those ports is allowed.

Bibliography

The main page of the IBM documentation on NetServer can be consulted at this link: https://www.ibm.com/docs/en/i/7.5?topic=services-i-netserver . Other useful resources can be found in the attached document:

In the next article we will talk about how control accessto NetServer.