- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Backup and 000000.dir
Categories
Company
Local Language
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
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
Community
Resources
Forums
Blogs
- 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
тАО02-26-2008 03:58 AM
тАО02-26-2008 03:58 AM
tries to do a backup of dsa2:[x.y]toto.dat x:toto.dat. The backup works fine.
But in audit I get a READ access violation on dsa2:[000000]000000.dir. Which has W:E.
Why is backup doing this read and how to solve this problem ?
Wim
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-26-2008 04:05 AM
тАО02-26-2008 04:05 AM
Re: Backup and 000000.dir
what was the exact backup command and how is logical X defined?
I am not able to reproduce this.
regards Kalle
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-26-2008 04:15 AM
тАО02-26-2008 04:15 AM
Re: Backup and 000000.dir
and ops$mail [exec] ops$root:[mailfiles] /sys
and ops$root [exec] disk:[operations.] [conc] /sys
But I tried to replace dsa2:[x.] by a concealed device and then it works fine without alarm.
It seems that backup needs read access on all directory levels ? Then why if it also works without the access.
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-26-2008 04:32 AM
тАО02-26-2008 04:32 AM
Re: Backup and 000000.dir
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-26-2008 04:43 AM
тАО02-26-2008 04:43 AM
Re: Backup and 000000.dir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-26-2008 01:17 PM
тАО02-26-2008 01:17 PM
SolutionThe purpose of BACKUP is to reproduce the set of files being backed up. This includes all the attributes of all directories in the entire directory tree.
If BACKUP can't read the attributes, a directory won't be physically included in the saveset - though its existence can still be inferred from the filespecs of the saved files. On restore BACKUP will create *A* directory, with the correct name, but with whatever default owner, protection, version limits etc... are applicable. Your SET WATCH output shows BACKUP reading the directory attributes.
%XQP, Thread #0, Volume protection: Access requested: 00000001, Status: 00000001, PrvUsd: 00000000
%XQP, Thread #0, File protection (4,4,0): Access requested: 00000001, Status: 00000001, PrvUsd: 00000001
%XQP, Thread #0, Read attributes: File header 000000.DIR;1 (4,4,0)
%XQP, Thread #0, Read attributes: Back link 000000.DIR;1 (4,4,0)
%XQP, Thread #0, Read attributes: ASCII file name, type & version 000000.DIR;1 (4,4,0)
%XQP, Thread #0, Access 000000.DIR;1 (4,4,0) Status: 00000001
In your case the first BACKUP command implicitly references the "real" 000000.DIR, whereas the concealed device skips it - instead it references a "virtual" 000000.DIR, being the root of the concealed device (to which it DOES have read access).
By default, the 000000 directory usually has W:E access - this allows a non-privileged user to traverse the directory, but not to search it. Normal security practice. It also blocks non-privileged users from reading the directory attributes.
So, your BACKUP is working, except that it can't save 000000.DIR explicitly. The BACKUP command won't give you any errors, and the restore will work correctly (since you won't need to restore 000000.DIR, it doesn't matter that its attributes weren't saved), but you will correctly see a read failure audit on the directory, because that's what you've asked for. However, if you were to perform a full backup of this disk, with the same non-privileged user, and your 000000.DIR has non-default attributes, the restore wouldn't reproduce it.
I'm not sure which part of this you consider a problem. The BACKUP is doing exactly what you asked, within the constraints you've imposed on it.
You can either ignore the audit, give your process READ access to 000000.DIR, use the concealed device to skip 000000.DIR or increase the privileges of the process.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-26-2008 11:03 PM
тАО02-26-2008 11:03 PM
Re: Backup and 000000.dir
This is what I suspected. I didn't think of the fact that READ access is required to get the full information of the file.
I granted READ access.
Thx
Wim