FSUMF353 __chattr() could not set audit_flag_type audit flags for filename When Converting From HFS To ZFS

book

Article ID: 52794

calendar_today

Updated On:

Products

CA Cleanup CA Datacom CA DATACOM - AD CA CIS CA Common Services for z/OS CA 90s Services CA Database Management Solutions for DB2 for z/OS CA Common Product Services Component CA Common Services CA Datacom/AD CA ecoMeter Server Component FOC CA Easytrieve Report Generator for Common Services CA Infocai Maintenance CA IPC Unicenter CA-JCLCheck Common Component CA Mainframe VM Product Manager CA Chorus Software Manager CA On Demand Portal CA Service Desk Manager - Unified Self Service CA PAM Client for Linux for zSeries CA Mainframe Connector for Linux on System z CA Graphical Management Interface CA Web Administrator for Top Secret CA CA- Xpertware CA Top Secret CA Top Secret - LDAP CA Top Secret - VSE

Issue/Introduction

Description:

When converting from HFS to ZFS (using HFSSEC security in CA Top Secret), the IBM REXX exec to copy HFS file to ZFS file results in the following error:
FSUMF353 __chattr() could not set audit_flag_type audit flags for filename

Solution:

Here are some things to check regarding this error:

  1. Have an SCA acid that is a superuser issue the Unix "find" command to list all files that have auditor audit options set to "fff":
      find / -aaudit =f                                                        
    Issue the Unix "df" command to display mounted filesystems.

    Check every mounted filesystem in the "df" output to see if it also shows up in the "find" command output. If so, the auditor audit options for that filesystem should be changed from "fff" to "---" (no auditing).

    Issue the Unix chaudit command to change the auditor audit options from "fff" to "---". This example changes the auditor audit options for the /SERVICE filesystem:
      chaudit -a -f /SERVICE                                                   
    Issue similar chaudit commands for every filesystem that has incorrectly set auditor audit options.

  2. Be sure the directories are mounted as read/write and NOT as READ only.

  3. Check to see if there are old HFS files that have the auditor flags enabled? This error could occur for older HFS files which have the auditor flags enabled. If this is the case, copy the files from one HFS to another newer HFS and then convert to a ZFS.

    1. If the files are shared by two lpars, if one lpar owned the mount, the audit file can not be changed from the other lpar.
    2. If some directories were mounted as read only, the mount had to be changed to read/write in order to remove the flag.

If none of the above correct the problem, a security trace with the AUDIT attribute also on the acid, OMVS trace, and TSSOERPT will be needed to pursue.

Here are the instructions to activate the traces.

  1. TSS ADD(acid) TRACE AUDIT
  2. TSS REFRESH(acid) JOBNAME(*)
  3. TSS MODI(SECTRACE(ACT,WTL))
  4. ST SET,TYPE=OMVS,FUNC=ALL,END (issued on the console)
  5. This will route all trace records to the MVS syslog....
  6. Recreate the problem.
  7. TSS MODI(SECTRACE(OFF))
  8. ST DEL,ID=xx (issued on the console)
  9. TSS REM(acid) TRACE
  10. TSS LIST(acid) DATA(ALL,PROFILE)
  11. Please email trace to [email protected] with the issue number as the subject.

For the TSSOERPT, there is sample jcl in member TSSOERPT in the TSS SAMPJCL library. See also chapter 9 of the TSS 12.0 Report and Tracking Guide for more info on TSSOERPT.

Environment

Release:
Component: AWAGNT