CPF9802: Not authorized to object

What it means

CPF9802 is an escape message from QCPFMSG with the text "Not authorized to object &2 in &3". It means the lookup worked. The object exists and the library could be searched. What failed is the authority check on the object itself.

Every operation needs a certain level of authority. Calling a program or reading a file needs *USE. Adding, changing or deleting records in a file needs *CHANGE. Deleting, moving or renaming the object needs object existence or object management authority. If the user profile doesn't hold enough, the system refuses and sends CPF9802.

IBM i works out a user's authority from several places. It looks at *ALLOBJ special authority, private authority given to the user, authority given to the user's group profiles, an authorization list that secures the object, and the *PUBLIC authority. Authority adopted from a program on the call stack that runs under its owner's profile also counts. So the user might have had access yesterday through a group or an adopting program and lost it after a change somewhere else.

Common causes

• The user is new, or changed roles, and was never given authority to the object or to the group profile that has it.
• The object's *PUBLIC authority is *EXCLUDE or too low, and the user has no private or group authority to make up for it.
• A program that used to adopt its owner's authority (USRPRF(*OWNER)) was recompiled with USRPRF(*USER), or its owner changed, so the user no longer borrows the owner's rights.
• The object was restored or re-created. A new object usually gets its *PUBLIC authority from the library's CRTAUT value, and a restore to another system can leave it without the private authorities it had.
• The authorization list that secures the object was changed, or the object was taken off it.

How to find the problem

1. Open the job log with DSPJOBLOG, put the cursor on CPF9802 and press F1 to see the full object name and library. F9 shows which program received it.
2. Run DSPOBJAUT OBJ(ACCTLIB/PAYMAST) OBJTYPE(*FILE) to see the owner, *PUBLIC authority, the private authorities and any authorization list.
3. Run DSPUSRPRF for the user to see its group profile and supplemental groups, then check whether any of them appear in the object's authority list.
4. If security auditing includes *AUTFAIL, the audit journal QAUDJRN holds an AF (authority failure) entry for each refusal. Your security officer can read these with DSPJRN or the audit journal SQL services.
5. If a program is supposed to adopt authority, DSPPGM shows its owner and whether it runs under the user's or the owner's profile.

How to fix it

• Grant only the authority needed, for example GRTOBJAUT OBJ(ACCTLIB/PAYMAST) OBJTYPE(*FILE) USER(CLERK01) AUT(*CHANGE). The object's owner or a security officer has to run it.
• Prefer granting to a group profile or an authorization list over single users. That way the next new user only needs the right group.
• If an adopting program lost its rights, recompile or change it back to USRPRF(*OWNER) with the right owner, after your security team agrees.
• Don't give users *ALLOBJ to get past one error. It opens the whole system.
• Remember that the user also needs *EXECUTE authority to the library. If that is missing, the message is CPF9820, not CPF9802.

What it looks like

Not authorized to object PAYMAST in ACCTLIB.

DSPMSGD MSGID(CPF9802) MSGF(QSYS/QCPFMSG)

Technical reviewer: Albert Joseph, WND Software.

Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s documentation for your IBM i release.