Showing results for 
Search instead for 
Did you mean: 

Too many /.SeCuRiTy.xxxxxx files

Level 3


We have Veritas NetBackup 7.7.3 on Solaris 10.

When trying to restore a directory containing millions of files, NetBackup creates extra millions of /.SeCuRiTy.<num> files (as many as the restored files) in the root directory, they are very small files containing just file attributes of the restored files, and they seems to be used by NetBackup to change file attributes after restore.

  • 1st, I think this method not so pretty. Why didn't NetBackup just store these file attibutes in one single file?
  • 2nd, with these millions of small files I got my root directory saturated in inodes, even it still have gigabytes of free space, so no more /.SeCuRiTy.<num> files could be created anymore, and I wonder if this issue has any impact on my restore (e.g.: some files may have wrong attributes).
  • 3rd, is there any way we can configure NetBackup to store these /.SeCuRiTy.<num> files in other partition? Or can we just disable the creation of these files?

Thanks in advance



Level 6

Hi @Raek 

This seems strange behaviour and I have not seen this before (but may have missed this before). 

If noone else can suggest a fix, can you supply the follwing information.

What is the backup type you are restoring and where is it being restored to - what other options have you set in the GUI or the command line? What are the file system types for the original backup and the restore destination also? Is the restore client also Solaris 10?

Are the /.SeCuRiTy.nnn files being generated on the restore host or the master server?


Hello David

Here are the requested info:

  • The backup type is standard
  • Backup client: Solaris 10 SPARC
  • Restore client: to master server, Solaris 10 SPARC
  • Backed up from NFS (v3 or v4)
  • Restored to other NFS (v3)
  • Backup from GUI with no special options
  • Restore from GUI with no special options but restore in different path
  • /.SeCuRiTy.nnn are generated on restore client which is the master server in my case
  • File content sample:
    cat /.SeCuRiTy.800000

Hope this helps


Partner    VIP   

Hi @Raek

I had a faint memory of this from past times, and found this thread

To me this does look like a issues with different file systems types and owners.

If Netbackup cannot find/set a user during restore, I have some memory about Netbackup restoring those files as belonging to the root user for maximum security. This could explain why files are being written to root directory. 

Hello Nicolai

Thanks for your feedback.

Yes the /.SeCuRiTy.nnn files seem to be related to ACLs as mentioned in your article, and I guess they are stored by NetBackup when it can't set destination file's ACL. Below output from user_ops logs.

08:59:29 (4310795.001) Changed /SrcNFS/file1.tar.gz to /DstNFS/file1.tar.gz
08:59:29 (4310795.001) Unknown file type ''' for .SeCuRiTy.9, extracted as normal file
08:59:29 (4310795.001) ACLs of /DstNFS/file1.tar.gz restored to .SeCuRiTy.9

My restore completed successfully and with the right files' user/group id even if there were no more inodes for NetBackup to create the /.SeCuRiTy.nnn files.

So my probleme is just the fact that NetBackup eats all inodes of my root directory and leaving the system in a bad situation, so I have to manually cleanup these millions of files all time during restore operation.

I hope to find a good explanation of this strange behavior and a solution or workaround to fix it.

Partner    VIP   

Hi @Raek 

Unknown file type ''' for .SeCuRiTy.9, extracted as normal file

A idea to explain what you are seing, if the backup source is a normal file system, but exported as NFS, then the file system ACL's are recorded by Netbackup during backup operation, becuase the file system is considered a normal file systems and not NFS. But when the data is then restored to a NFS share, then the ACL cannot be applied and you will see the extracted ACL files in the root folder.

As a workaround, set root home directory temporary to a file system large enough to handle the SeCuRiTy files ( I don't know if that is possible on Solaris).

On the backup source, try running the Netbackup command bpmount, to see what file system type Netbackup think it is.

Hello Nicolai

Thanks for your feedback.

I confirm the source FS that was backed up from source client is a NFS. It is not a local filesystem exported as NFS.

When I run bpmount the output doesn't show my source mountpoint since it is NFS. The command shows local FS only.

I think the workaround of increasing root FS may work but it is too heavy operation as workaround, since my root FS is UFS and can't be extended online. It must be backed up, recreate volume/FS then restore.

Deleting the /.SeCuRiTy.nnn files with a cronjob is lighter workaround. I'll still search for a better solution however.

Hi Nicolai

Sorry for my mistake but after doublecheck I found that source client is Red Hat.

That explains the incompatibility with ACLs and the generation of /.SeCuRiTy.nnnn files.

Partner    VIP   

Hi @Raek 

That is the cause, cross OS restore is not supported,  even though both clients are using policy type "standard".

Glad I could help :)

Best Regards