Backups and restores may fail, or troubleshooting may be hindered if the NetBackup log directories are not readable and writeable by user and application processes.

Article: 100029340
Last Published: 2013-11-21
Ratings: 3 0
Product(s): NetBackup & Alta Data Protection

Problem

Backups and restores may fail, or troubleshooting may be hindered if the NetBackup log directories are not readable and writeable by user and application processes.
 

Solution

Overview:
NetBackup uses the /usr/openv/netbackup/logs (UNIX/Linux) or <install>\NetBackup\logs (Windows) directory tree not only for the recording of troubleshooting information, but also for progress updates to users and communication updates to other NetBackup processes.  Restrictive permissions on these directories can not only disable the collection of troubleshooting data, but also prevent the application from functioning correctly. 
  
Detail/Symptom(s):
Backup and restore operations will fail when permissions are too restrictive as shown by these log entries.

When the user of the Java GUI does not have permission to create a subdirectory within net backup/user_ops.

Protocol Code: 101
Status: 35
Error Msg: cannot make required directory
Server Locale: C
TO[0]: doe
TO[1]: data1
TO[2]: C
TO[3]: XXXX
TO[4]: auth.conf
TO[5]: 600000 IPC
FROM[0]: cannot make required directory
Aux data: null

When a database extension does not have permissions to create a comm file for the server processes to update.

<16> openProgressFile: ERR - can't make directory path: </usr/openv/netbackup/logs/user_ops/dbext/logs>: 13
<16> CreateNewImage: ERR - openProgressFile() failed
<16> VxBSACreateObject: ERR - Could not create new image with file /bk_10_1_616580548.
<16> xbsa_CreateObject: ERR - VxBSACreateObject: Failed with error:
Server Status:  Communication with the server has not been initiated or the server status has not been retrieved from the server

When a database extension does not have permission to read updates from the comm file created by the server processes.

<16> openProgressFile: ERR - can't access path: <%s>: Permission denied (13)

or

<16> openProgressFile: ERR - failed to open comm file:<13>:</usr/openv/netbackup/logs/user_ops/dbext/logs/16393.0.1027628582>

When a database extension does not have permissions to exchange application data between client side processes.

13:27:19 ERR - Lock file usr/openv/netbackup/logs/user_ops/dbext/logs/vxbsa.1204633605.14081.files.1.lock is unlocked. Abort backup.

or

13:26:43.205 [14081] <2> create_sap_file_list: Creating file list container /usr/openv/netbackup/logs/user_ops/sap/.filelist.1204633602.14081
13:26:43.205 [14081] <16> create_sap_file_list: ERROR: couldn't open file container path: /usr/openv/netbackup/logs/user_ops/sap/.filelist.1204633602.14081


Resolution:

The recommendation is to make the /usr/openv/netbackup/logs (UNIX/Linux) and <install>\NetBackup\logs (Windows) subdirectories readable and writeable by all users.  However, if security requirements prohibit global read/write access, the permissions of specific directories can be restricted to a single group or user if all backup and restore operations related to that directory are initiated by processes that run as members of that group or as that user.  

Most critical is the user_ops subdirectory and its subdirectories.  These must exist and be accessible for the applications to operate correctly.  The following processes use files within this directory tree.
 
  • Processes invoked by native database backup and restore utilities; Oracle rman, SAP brbackup, Informix onbar, Sybase isql, DB2 db2, SQL-Backtrack obackup, etc.  These processes typically run as a specific database user, but there may be multiple instances on the host running as different users.  In the case of SAP, there may be an SAP user and an Oracle user, both may need access.  Be aware that these backups are often invoked from scripts that switch the user before invoking the backup/restore utility and the utility program files themselves may also be installed SetUID or SetGID.  The effective user of the running process needs permission to create/write/read/delete files.
  • The NetBackup database extension wizards (e.g. bpdbsbora and bpdbsbdb2) which execute backup and restore templates.  These are typically execute as the same user(s) as the database backups noted above.
  • The NetBackup Java GUIs (e.g. jbpSA and jnbSA) when run by a user who has permission to submit client-side user-directed backup or restore operations.  Please note that this includes the Lotus Notes administrator for client-side initiated restores.
  • A snapshot of the most common users and groups that need access can be obtained by creating the directories with 777 and observing the files that get created therein over the next few days or weeks.
  • If database extensions are not used and only the root user can initiate user-directed operations, then the permissions can be restricted to just the root user.
Restricting the permissions on the other directories located in the  logs directory will not impact operations but may hinder troubleshooting efforts when processes do not have the appropriate permissions to update the debug logs therein.  These directories are optional and are temporarily needed only during troubleshooting:
 
  • bpbkar logs are normally only written by 'root'.  The process does a switch user after the process is active and the file descriptors for the log file is already open.
  • tar logs are normally only written by 'root', however the Lotus Notes and other database extension user must also have privileges since the restore is invoked by that user.
  • The dbclient directory must be writeable by the Oracle, SQL-Server, or Teradata user that is performing the backup or restore.
  • The bpdbsborabpubsora, and nbbrowse directories must be writeable by the Oracle user that is performing the backup or restore.  On UNIX/Linux, the nbbrowse directory is located in /usr/openv/logs.
  • The bpdb2, bpdbsbdb2, bpubsdb2, and nbrowse directories must be writeable by the DB2 user that is performing the backup or restore.  On UNIX/Linux, the nbbrowse directory is located in /usr/openv/logs.
  • The infxbsa directory must be writeable by the Informix user that is performing the backup or restore.
  • The backint directory must be writeable by the SAP or Oracle user that is performing the backup or restore.
  • The nb_obsi directory must be writeable by the SQL-Backtrack or Oracle or Sybase or Informix user that is performing the backup or restore.
  • The sybackup directory must be writeable by the Sybase user that is performing the backup or restore.
  • The bpbackup, bplist, and bprestore directories must be writeable by the database user or other users that either utilize those commands directly or utilize the comparable NetBackup Java GUI features to queue requests to the master server.
  • The bpbrm, bpcd, bpfilter, bphdb, bprd, bpsched, bptm, and vnetd processes only execute as root and those directories do not require additional permissions.

Other NetBackup troubleshooting log directories may be needed occasionally.  They should be created, temporarily, with the assistance of NetBackup technical support.

On Windows, the ACLs can be viewed or changed in the Windows Explorer.  On UNIX/Linux, the access to the directories can be reviewed and changed using the following commands.

$ ls -l /usr/openv/logs
$ ls -lR /usr/openv/netbackup/logs
$ chmod <new_modes> <target_directory>
$ chgrp <new_group> <target_directory>
$ chown <new_owner> <target_directory>

If recreating directories that were deleted, set the umask appropriately before creating the directory.

The Sticky Bit

The affects of this feature are operating system dependent, but some sites may find it beneficial to set the sticky bit on  various directories beneath /usr/openv/netbackup/logs.  NetBackup does not recommend or prohibit the use of this feature as long as it does not interfere with the creation, access, update, or removal of the files as needed by NetBackup.  Simply ensure that backup, browse, and restore functionality is working as expected for all users after enabling the feature, and that file cleanup is not adversely affected otherwise the disk volume will fill and operations will fail or behave erratically.

This is most evident on hosts where operations are conducted by processes running as more than one non-root user.  When the next operation runs as the other user, it may log errors relate to the inability to cleanup  temporary or debug files created by the prior operation and owned by that user.  E.g.

<4> openProgressFile: cleaning directory: </usr/openv/netbackup/logs/user_ops/dbext/logs>
<4> delete_old_files: entering delete_old_files.
<8> delete_old_files: WRN - Cannot unlink /usr/openv/netbackup/logs/user_ops/dbext/logs/9999.0.1234567890. Errno = 13: Permission denied
...snip...
<4> VxBSAEndTxn: INF - Cleaning directory: </usr/openv/netbackup/logs/dbclient>
<4> delete_old_files: entering delete_old_files.
<8> delete_old_files: WRN - Cannot unlink /usr/openv/netbackup/logs/dbclient/log.010110. Errno = 13: Permission denied

The warnings are non-fatal, but the files may need to be manually remove if the original user does not initiate a later operation.
 

 

 

 

References

Etrack : 1049798 JIRA : null Etrack : 3348858

Was this content helpful?