Troubleshooting NetServer File Copy Errors

I just authorized a user for read-write access to an iSeries NetServer file share in the QDLS file system on my system i machine. However, when he tries to copy a text file to that folder, he gets a Windows error saying ‘Cannot copy file: Access is denied. Make sure the disk is not full or write-protected and that the file is not currently in use.‘ I can write to the QDLS folder and he has the same authority that I do. Do you know what’s going on here?

–Bob

It’s been my experience that this error is usually an authority issue rather than a disk space problem. Chances are good that the authority problem is on the i5/OS side rather than on the network or in Windows. Here’s my checklist of things to review when searching for a NetServer authorization problem.

1.    Check to see if the user profile is disabled from using iSeries NetServer. If the user signs on to the system too many times with the wrong password, they can lose iSeries NetServer access. When this happens, the operating system sends a CPIB682 error message (User profile &1 disabled for iSeries Support for Windows Network Neighborhood access) to the QSYSOPR message queue. If you see one of these messages in QSYSOPR, it is confirmation that the user is disabled for NetServer access (note: users can be disabled for NetServer access without being disabled for regular i5/OS access).

To re-enable iSeries NetServer access for disabled profiles, open iSeries Navigator (OpsNav) and locate the iSeries NetServer icon by following the Network –> Servers –> TCP/IP path under your user’s target partition. Right-click on the iSeries NetServer icon in the right-hand pane and select Disabled User IDs from the pop-up menu that appears. On the User IDs Disabled for iSeries NetServer Window that comes up, re-enable the user ID and ask the user to try the transfer again.

2.    Look at the NetServer job that this user is connected to. We can assume that the iSeries NetServer server (QZLSSERVER) job is up and running since your user can connect to the share. So the next step is to check out the NetServer QZLSFILE or QZLSFILET prestart jobs (QZLSFILEn) that the users connect to when they perform file operations on your NetServer share. The QZLSFILE prestart jobs support single client non-threadsafe sign ons to NetServer. The QZLSFILET prestart jobs support multiple client threadsafe sign ons for NetServer. Your system may or may not use both the QZLSFILE and QZLSFILET prestart jobs. You’ll need to look at these QZLSFILEn jobs while the user has the error on his desktop. On my i5 box, the QZLSFILEn jobs are found in the QSERVER subsystem, and you can view all the jobs in that subsystem by performing the following Work with Active Jobs command (WRKACTJOB).

WRKACTJOB SBS(QSERVER)

Be aware that on some systems, these jobs can be configured to run in another subsystem. So if you don’t find the jobs here, check all subsystems in the WRKACTJOB command to see where the QZLSFILEn jobs are located.

Press F14 on the WRKACTJOB display to include any inactive prestart jobs that are not automatically shown on the default display. This will insure that you can see all the QZLSFILEn that are active on your system.

On the WRKACTJOB screen, place a ‘5’=Work with job in front of the first QZLSFILEn job in the subsystem. Press ENTER. On the Work with Job screen that appears, take option 10 to display the job log for this job. If this is the job that the user is connecting to NetServer with, you’ll see a CPIAD12 message in their job log that says ‘Servicing user profile xxxxxxxxxx from client nnn.nnn.nnn.nnn’, where xxxxxxxxxx is equal to the user profile name you are trying to debug NetServer for and nnn.nnn.nnn.nnn is equal to the IP address that the user is trying connect to the NetServer server from. If you don’t see the user profile name in the job log, go back to the WRKACTJOB screen and check the next QZLSFILEn job entry in the list.

Once you find the user’s QZLSFILEn job, look for any error messages in the job log. In particular, check to see if the CPF9006 error (User not enrolled in system distribution directory) is present. If it is, go to step three. Otherwise, go to step four.

3.    If the QZLSFILEn job that the user is attached to had a CPF9006 error, check the system distribution directory to make sure that the user has a valid system distribution directory entry. Many applications will not run correctly if the user does not have a valid directory entry. To view the directory, use the Work with Directory Entries command (WRKDIRE) off the green-screen. If there isn’t a valid entry for this user, add an entry for the user. If the user does have a directory entry, delete the entry and enter it again with the same information. A description of how to use WRKDIRE can be found in IBM’s CL Commands manual. Try copying the text file from Windows to the NetServer file share again. It should work now.

4.    If you found any other specific error messages when looking at the user’s QZLSFILE job, take whatever steps are necessary to correct the errors and try again. Go to step five if that still doesn’t do the job.

5.    Check to make sure that the user has the proper authorities to the NetServer file share. You can check the share authorities in iSeries Navigator (OpsNav) by opening the Network –> Servers –> TCP/IP node under your target i5/OS partition. Right-click on the iSeries NetServer entry in the right-hand pane of the screen and select Open from the pop-up menu that appears. This will bring up the iSeries NetServer configuration Window, which shows a tree of your NetServer Shared Objects (file shares) and the open NetServer Sessions. Open the Shared Objects node, right-click on the NetServer file share that your user is trying to copy to, and select Permissions from the pop-up menu that appears. This displays a list of all the users or groups who have access to that file share. To be able to add new text files to your folder, the user should at least have Read, Write, and Management authority to the target share. If not, authorize him to the share with those authorities and add any other authorities as needed. Try the text copy file again.

6.    Go into the QDLS folder that the file share is attached to and make sure that the user has the proper authorities to create objects in that folder. On the green-screen, you can get to that folder by running the following Work with Object Links command (WRKLNK).

WRKLNK OBJ(‘/QDLS/*’)

Place a ‘9=Work with authority’ in front of the NetServer share folder he is trying to access and press ENTER. The user should have Read and Write authorities (*RW) to the folder. If not, add those authorities to that folder for his user profile and try the transfer again.

7.    If none of the other steps work, check the object authority for the Root (/) directory of the AS/400 Integrated File System (AS/400 IFS) and add Read, Write, and Execute authorities for the *PUBLIC user, if these authorities aren’t already present for the Root (/). Even though it seem counter-intuitive to give the *PUBLIC user virtually all authority to the AS/400 IFS Root (/) directory, IBM recommends that you do this in order for your users to access necessary system objects that they need to run their applications. Although this isn’t the likely solution, sometimes this authority can be changed by an over-zealous administrator and the solution is to change it back. Instructions for changing Root (/) authority can found in an earlier article I wrote called Dissecting the Unusual QLGPGCMA.LOCALE Error.

This is the drill I have for insuring that the user is authorized to everything he needs to update data on a NetServer file share. Please try running through these steps and see if it helps with your problem.

Follow-Up and Solution

Bob ran through the checklist and it turned out that there was a problem with the user’s system distribution directory entry. Once the entry was deleted and recreated, the file transfer worked fine.

About Our Testing Environment

Configurations described in this article were tested on an i5 550 box running i5/OS V5R3. Many of the commands may also be available in earlier versions of the operating system running on iSeries or AS/400 machines. If a command is present in earlier versions of the i5/OS or OS/400 operating systems, you may notice some variations in the pre-V5R3 copies of these commands. These differences may be due to command improvements that have occurred from release to release.

–Joe

RELATED STORIES

CL Commands manual, IBM

Dissecting the Unusual QLGPGCMA.LOCALE Error

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot