- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- ACL or file permission issue
Operating System - OpenVMS
1753781
Members
7476
Online
108799
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Go to solution
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-15-2010 04:08 PM
тАО04-15-2010 04:08 PM
This question involves renaming a file owned by one user to a directory owned by another user. The 2 user accounts involved are savftp and savjob.
The savftp account is a drop off point for files that are processed by user savjob.
The default directory for savftp has the following acl entries:
Directory USR$DISK1:[000000]
SAVFTP.DIR;1 [SAVFTP] (RWE,RWE,RE,)
(IDENTIFIER=[SAVJOB],OPTIONS=DEFAULT,ACCESS=READ+DELETE)
(IDENTIFIER=[SAVJOB],ACCESS=READ+WRITE+DELETE)
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)
Directory USR$DISK1:[SAVJOB.ENTDBA.ARC]
[SAVFTP] (RWED,RWED,RE,)
(IDENTIFIER=[SAVJOB],ACCESS=READ+DELETE)
TO_RECONCILE.OLD;1335
[SAVFTP] (RWED,RWED,RWED,)
TO_RECONCILE.OLD;1334
If I remove the ace and set the file permissions to be the same as TO_RECONCILE.OLD;1334; the job works once.
The next run fails with the errors previously listed.
How do I fix this?
Thanks in advance
Kevin
The savftp account is a drop off point for files that are processed by user savjob.
The default directory for savftp has the following acl entries:
Directory USR$DISK1:[000000]
SAVFTP.DIR;1 [SAVFTP] (RWE,RWE,RE,)
(IDENTIFIER=[SAVJOB],OPTIONS=DEFAULT,ACCESS=READ+DELETE)
(IDENTIFIER=[SAVJOB],ACCESS=READ+WRITE+DELETE)
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)
Directory USR$DISK1:[SAVJOB.ENTDBA.ARC]
[SAVFTP] (RWED,RWED,RE,)
(IDENTIFIER=[SAVJOB],ACCESS=READ+DELETE)
TO_RECONCILE.OLD;1335
[SAVFTP] (RWED,RWED,RWED,)
TO_RECONCILE.OLD;1334
If I remove the ace and set the file permissions to be the same as TO_RECONCILE.OLD;1334; the job works once.
The next run fails with the errors previously listed.
How do I fix this?
Thanks in advance
Kevin
Solved! Go to Solution.
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-15-2010 04:31 PM
тАО04-15-2010 04:31 PM
Solution
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:
$ exit %x910
%SYSTEM-W-NOSUCHFILE, no such file
$
http://labs.hoffmanlabs.com/node/1450
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:
http://labs.hoffmanlabs.com/node/426
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:
$ exit %x910
%SYSTEM-W-NOSUCHFILE, no such file
$
http://labs.hoffmanlabs.com/node/1450
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:
http://labs.hoffmanlabs.com/node/426
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-16-2010 12:41 AM
тАО04-16-2010 12:41 AM
Re: ACL or file permission issue
Kevin,
What does the following command show?
$ directory/security USR$DISK1:[SAVJOB.ENTDBA]ARC.DIR
What is the raname command being used?
You may want to use rename/inherit_security
$ help rename /inherit_security
Jon
What does the following command show?
$ directory/security USR$DISK1:[SAVJOB.ENTDBA]ARC.DIR
What is the raname command being used?
You may want to use rename/inherit_security
$ help rename /inherit_security
Jon
it depends
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-16-2010 12:04 PM
тАО04-16-2010 12:04 PM
Re: ACL or file permission issue
The access issue was determined by enabling file access failure alarms, this enabled me to determine why the rename was failing.
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP