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.
- 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
To view the list of disabled users for NetServer you can use option 12 of the NETS menu (on the topic of NetTools re-read the article NetServer for everyone – part 3 ) and re-enable them with option 7.
Or you need to connect to Navigator for i, from the icon Net choose the voice Server > TCP/IP servers. From the list look for the item NetServer and from the contextual menu choose the item User IDs disabled.
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
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.
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:
CHGPJE SBSD(LIBL/QSERVER) PGM(QZLSFILE) STRJOBS(NO)
ENDPJ SBS(QSERVER) PGM(QZLSFILE) OPTION(*IMMED)
CALL QZLSENDS PARM(x'00000000')
CALL QZLSSTRS PARM('1' x'00000000')
If the service starts successfully, run:
CHGPJE SBSD(LIBL/QSERVER) PGM(QZLSFILE) STRJOBS(YES)
STRPJ SBS(QSERVER) PGM(QZLSFILE)
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.
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.