User savjob processes the file in the usr$disk1:[savftp] directory. After processing the file user savjob attempts to rename the file to a directory owned by savjob on the same device. The rename fails with the following errors:
%RENAME-E-OPENOUT, error opening USR$DISK1:[SAVJOB.ENTDBA.ARC]TO_RECONCILE.OLD; as output -RMS-E-ENT, ACP enter function failed -SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
As you can see the error happens when savjob tries to write to its own directory.
This process worked prior to migrating from another server with the same OS version, which by the way is OpenVMS 8.2, both systems are at the same patch level.
The old file in the USR$DISK1:[SAVJOB.ENTDBA.ARC] has its protection set to (RWED,RWED,RWED,)
When the new version of TO_RECONCILE.OLD is written it comes with the ace (IDENTIFIER=[SAVJOB],ACCESS=READ+DELETE)
SAVJOB needs write access to the directory to SAVFTP.DIR, as a start. (The RENAME requires SAVJOB to update that directory file.) That's the apparent trigger here, though there may be others lurking.
In general, a tool to use here is file access alarms. Or audits, on a busy system. Enable file access failures. That'll tell you what failed.
If the commands can (also) be run interactively, another tool is "SET WATCH /CLASS=MAJOR FILE" or SET WATCH /CLASS=ALL FILE" such; the CLASS varies. Use SET WATCH /CLASS=NONE FILE" to shut off output. CMEXEC or CMKRNL is required. Look for the failure codes.
You can translate these failure codes with, for instance:
Given you had another system involved, the ACLs can be all over the map if the SYSUAF and RIGHTSLIST don't match. I updated a tool to clean off ACLs for these cases:
