Last Updated on 20 August 2020 by Roberto De Pedrini
Index
Introduction
The IBM i operating system provides the IBM i NetClient file system (QNTC) which allows access to data and objects stored on remote servers. Properly configured it allows access to Windows NT 4.0 or higher, Linux Samba 3.0 or higher and supported versions of IBM® i NetServer.
More generally, through QNTC it is possible to access, for example, shared network folders, read and write files directly from the IBM i system, and in these cases, for example, it is possible to use commands such as CPYTOIMPF or CPYFRMIMPF to write or read from stream files and exploit the potential of the command or it is even possible to use FTP commands in particular to be able to write or read the remote directory directly.
In order for the IBM i server and the remote system to communicate and authenticate you need to know some essential assumptions and configuration details. This article is intended to be a help in trying to make the most of the QNTC avoiding some common mistakes that could drive even the most patient people crazy or in any case provide an idea to solve potential problems.
Assumptions and / or prerequisites for configuration
- Authentication between the IBM i system and the remote system occurs by exchanging the credentials of the current user of the IBM i server acting as client
- From QNTC you will only be able to view network folders shared on other servers
- The remote server must be enabled to receive signed digital communications
- QNTC does not support the concept of ownership of a file or directory
- If the IBM i system cannot view shared folders directly, you can force the name of remote servers as directories
If you have never used QNTC before and run the WRKLNK OBJ (‘/ QNTC’) command and then hit display option 5 you will probably find a situation similar to the following:
In order to access the folders of a known remote server, it is necessary to make the IBM i system understand which server you want to connect to and you can do it both through the host name and through the IP address of the server. It is possible to use the command:
MKDIR ‘/ QNTC / MySE
RVER’ In this case, assuming that MySERVER is a server on our network that we want to access (it can also be the IP address), the newly created directory will be displayed in QNTC. If everything is already configured correctly, selecting option 5 on ‘/ QNTC / MySERVER’ will display the shared network resources.
Authentication between the IBM i system and the remote system
The connection starts from the IBM i system trying to authenticate to a remote server with the current user. For example through the command:
WRKLNK ‘/ QNTC / MySERVER’
The IBM i server is requesting access to the MySERVER server based on the username and password of the current session and if so it will display the shared network folders. If nothing is shown and you are sure that shared network folders exist, the anomaly may probably be due to incorrect credentials or other potential problems. With the DSPJOBLOG command you can analyze the messages received and identify other errors, for example in this case it is an error code 5 of class 1 (the legend is in the next part of the message – “Access Denied”):
In order to authenticate to the server, the user name and password must be in common between the IBM i system and the remote system. In this regard, important assessments must be made as also indicated by the IBM documentation and below a summary of some relevant aspects:
If the QPWDLVL system variable is set to “0” or “1” the exchange of credentials will be case-insensitive by converting the characters from uppercase to lowercase. For example, if the password on IBM i is PIPPO1234 it will be converted into foo1234 which will in turn be used for authentication on the remote server. In this case the password on the remote server must be set to foo1234 for a correct authentication due to the implicit translation from upper case to lower case during the authentication phase.
If the QPWDLVL system variable is set to “2” or “3” the exchange of the credentials will be case-sensitive and consequently the password must be exactly the same in the two systems. Below is a link for further information on this issue:
https://www.ibm.com/support/pages/id-and-password-considerations-qntc-file-system
View shared folders
If authentication is successful and there are no anomalies, selecting option 5 on ‘/ QNTC / MySERVER’ will show the shared folders of the remote server reachable by IBM i. The folders displayed in QNTC will be the same that for example in a Windows server are shown with the folder sharing option and will be reachable in the directory ‘/ QNTC / MySERVER / Remote folder’.
For example, if on a server 192.168.0.1 we share a folder called “transit” and the IBM i server and server 192.168.0.1 share the credentials of the same user, it will be possible to access the remote folder using the WRKLNK ‘/QNTC/192.168 command. 0.1 / transit ‘and operate accordingly with file reading / writing through system commands or dedicated procedures.
Qualification for signed digital communications
In order to access a system, the remote system must be enabled to receive signed digital communications.
This message is one of the prerequisites that is required and is also indicated in the event of anomalies that can be found via the DSPJOBLOG command.
In slightly more recent systems this is a prerequisite set by default, therefore during the configuration phase it is less likely that it is necessary to intervene on the remote server to modify some security parameters that could also impact other applications. If it is necessary to intervene on these parameters it will be necessary to understand according to the operating system of the remote server which options are to be modified and you will have to ask for some system help!
QNTC does not support the concept of ownership of a file or directory
Remote authorization management is not possible from the IBM i system but must be managed directly on the system hosting the shared folder.
Therefore it will not be possible to use commands that change the permissions level of folders and / or files such as WRKAUT and CHGAUT.
Force server name as directories on QNTC
In an ideal world it is possible to browse the network and find the remote servers that QNTC can access and consequently, if you are authorized, be able to view the remote server folders.
Personally I have encountered some problems due to potential configuration problems and network scan and resolution times and I suggest to force the name of the remote server on which you want to work as a directory on QNTC.
As indicated above, to access a remote server it is possible to use the MKDIR ‘/ QNTC / MySERVER’ command indicating in MySERVER the host name or IP address to which we want to connect and in this way the IBM i system will be able to know in a “forced” way the new server to ask to authenticate to.
It is important to emphasize that this setting is maintained until the next IPL after which it will be lost. To keep these settings active following an IPL, you need to modify the starting program or enter the command MKDIR … within a job following an IPL.
Once the command is done by a user with adequate privileges, all processes that use QNTC can access the “forced” server and it will not be necessary to re-issue the command unless the remote directory is deleted.
Potential problems with QNTC and resolutions
The main problem in using the QNTC in the absence of authentication via single sign-on is to create a new user with relative password that can be shared between the IBM i server and the remote server to which you want to access. The username can also be a local username of the remote server that we want to access without being a domain user and this configuration can help solve some configuration problems.
In order to write to a shared remote folder it is therefore necessary to use a shared remote user but this binds several applications that may have to run with another username. If the application concerned runs with the USER1 user and to write to QNTC we use only the WRT_QNTC user, the application will not be able to write to QNTC because it will try to access the remote server with the USER1 user who is not authenticated.
To overcome this problem, it is possible to intervene in different and somewhat creative ways, here are some examples:
- It is possible to use the SMBJOB command by submitting the job that has to copy / transfer the file with the new username shared with the remote server. Of course this requires that the user running the SBMJOB with a new username have elevated privileges.
- It is possible to perform an FTP transfer on QNTC by logging in with the new user and the password shared with the remote server. For example, if we want to transfer the “TEST” file present in the “TEST” library on IBM i on the remote server “192.168.0.1” in the “transit” folder with the name “ciaoQNTC.txt” and our IBM i server is called “ServerIBMi “we could use an FTP command similar to the following:
- user / pwd (credentials of the new user shared with remote server)
- namefmt 1
- put ‘/QSYS.LIB/TEST.LIB/PROVA.FILE’ ‘/QNTC/192.168.0.1/transito/ciaoQNTC.txt “
- quit
The FTP command will be executed by opening a connection directly on the IBM i system such as STRTCPFTP RMTSYS (‘ServerIBMi’). In this way we ask the IBMi system to “play” with its file systems and we will obtain the desired result with the records already truncated at the last non-blank value to also optimize space.
- It is possible to delegate the sending to another process that does file management as a job. For example, a program that wants to transfer a file could execute a command we created which for convenience we call SENDFILE MyFile. A process in continuous listening, for example a DTAQ timed to a certain number of seconds that runs in a subsystem with the username / pwd shared with the remote server could take charge of the request and centralize all requests and solve the user’s problem doing the job. Personally, I think it is a good choice, perhaps integrating via parameterization also the option of transfer via FTP of the previous point within the listening job if requested.
Conclusions
In various companies there are often infrastructures with heterogeneous servers (Windows / Linux / IBM i …) that need to communicate by exchanging files or interacting with each other as needed.
There are different ways and technologies of solving the problem such as Web Services or file transfer via FTP or SFTP and other solutions.
QNTC allows you to do native integration from IBM i with different remote systems and to exchange information easily without making redundant file transfer steps. But keep an eye on security in general, maybe change the shared user’s complex pwd after a period of time to limit potential problems …
For more information you can consult the IBM documentation that I report below for completeness:
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/ifs/rzaaxqntcfs.htm
I believe that all of us who work in the IBM i environment have happened, and continue to do, to Read more
Viruses and malware in general, such as ransomware, can also damage IBM i if they find shared directories in the Read more
The numerous DB2 for i services recently have been enriched with a new category, that allows you to poke around Read more
FAQs, tips and howtos on IBM i System Administration collected from forums and other IBM i websistes. IFS, Backup, Security Read more
