Sun Microsystems, Inc.  Oracle System Handbook - ISO 7.0 May 2018 Internal/Partner Edition
   Home | Current Systems | Former STK Products | EOL Systems | Components | General Info | Search | Feedback

Asset ID: 1-72-2353754.1
Update Date:2018-01-29
Keywords:

Solution Type  Problem Resolution Sure

Solution  2353754.1 :   VSM6 and VSM7 - Permissions Denied when manually accessing Support File Bundles  


Related Items
  • StorageTek Virtual Storage Manager System 6 (VSM6)
  •  
  • StorageTek Virtual Storage Manager System 7 (VSM7)
  •  
Related Categories
  • PLA-Support>Sun Systems>TAPE>Virtual Tape>SN-TP: VSM6
  •  




In this Document
Symptoms
Changes
Cause
Solution


Oracle Confidential PARTNER - Available to partners (SUN).
Reason: service issue

Applies to:

StorageTek Virtual Storage Manager System 6 (VSM6) - Version All Versions to All Versions [Release All Releases]
StorageTek Virtual Storage Manager System 7 (VSM7) - Version 7.0.0 to 7.1.2 [Release 7.0]
Information in this document applies to any platform.

Symptoms

User vsmadm is unable to manually access directory /var/opt/StatusService/output in order to collect Support File Bundles that reside in the /var/opt/StatusService/output/archive directory.

An attempt to access the /output directory results in a “permissions denied” error.

The permissions and owner:group for directory /var/opt/StatusService/output indicate 766 root:root instead of 766 vsmadm:staff.

Incorrect:
vsmadm@vsmpriv1:/var/opt/StatusService$ cd output
-bash: cd: output: Permission denied
vsmadm@vsmpriv1:/var/opt/StatusService$ ls -al
drwxrwxrwx 10 vsmadm staff 11 Apr 16 2014 .
drwxr-xr-x 7 root sys 7 Aug 29 10:01 ..
-rwxrwxrwx 1 root root 4692 May 21 2013 README.txt
drwxrwxrwx 2 root root 11 Jan 10 10:24 bin
drwxrw-rw- 2 root root 11 Jan 10 13:02 etc
drwxr--r-- 2 root root 6 Jan 10 10:24 logfiles
drwxrw-rw- 3 root root 212 Jan 10 17:20 output
drwxrw-rw- 2 root root 3 Jan 10 17:20 output_logs
drwxrw-rw- 2 root root 207 Jan 10 17:20 previous_logs
drwxrwxrwx 2 root root 45 Jan 10 10:24 scripts
drwxrwxrwx 2 root root 2 Jan 10 17:20 tmp
vsmadm@vsmpriv1:/var/opt/StatusService$

Correct:
vsmadm@vsmpriv1:/var/opt/StatusService$ ls -l
-rwxrwxrwx 1 vsmadm staff 4692 May 21 2013 README.txt
drwxrwxrwx 2 vsmadm staff 11 Apr 16 2014 bin
drwxrw-rw- 2 vsmadm staff 11 Jan 18 19:49 etc
drwxr--r-- 2 vsmadm staff 6 Apr 16 2014 logfiles
drwxrw-rw- 3 vsmadm staff 184 Jan 26 14:15 output
drwxrw-rw- 2 vsmadm staff 3 Jan 26 14:15 output_logs
drwxrw-rw- 2 vsmadm staff 172 Jan 26 14:15 previous_logs
drwxrwxrwx 2 vsmadm staff 36 Apr 16 2014 scripts
drwxrwxrwx 2 vsmadm staff 2 Jan 26 14:15 tmp

 

Changes

Unknown.  This has been seen after a microcode upgrade to 7.1.1.xx.000 and 7.1.2.03.000, though it is not known why or if other actions caused the initial action.

It is possible that users logged in as root or used sudo bash to access root user, instead of user vsmadm during maintenance actions that do not require root access.

 

Cause

This is an intermittent situation and it is unknown how the system gets in this condition initially.
Engineering has found some incorrect permissions coding in the VSM code.

Solution

 This problem does not affect Support File Bundle creation or ASR SFB file uploads. It only affects USER=vsmadm when changing directories to manually collect a SFB.

Until changes are applied to future code, it is necessary to change owner first to manually collect Support File Bundles.

$ cd /var/opt/StatusService
$ sudo chown vsmadm:staff output

--then manually access the /var/opt/StatusService/output/archive directory to collect the SFB.

Note: after the next SFB is created, the changes will revert back to the original failed condition.


Attachments
This solution has no attachment
  Copyright © 2018 Oracle, Inc.  All rights reserved.
 Feedback