Netbackup SELinux, Restoring context on symbolic links

[JOHNRW]

We are having a problem where the SELunix context is not breing restored on Symbolic Links within SELinux.

i.e

Context before backup

lrwxrwxrwx. root root unconfined_u:object_r:httpd_config_t:s0 asoft1 -> file1

Context after restore

lrwxrwxrwx. root root unconfined_u:object_r:user_tmp_t:s0 asoft1 -> file1

We are using NBU 7.1.0.4

Is anyone else experiencing this problem, or as anyone already experienced it and has a work around.

Thanks in advanced

[RamNagalla]

Symboli link file do backup as link files only they do not take any data..

you need to restore from the source file to recover the data.

if your case.. locate the file1 in the backup image and do the restore of file1 to get the data..

[JOHNRW]

I already know how to restore thank you - it is the specific SELinux content that isnt being restored.

[RamNagalla]

so you did the restore from the source file 

attach the restore log to this discussion , to see if it can tell anything.. 

[Marianne · Accepted solution]

I found this in NBU 7.5.0.7 Release Notes under General NetBackup 7.5.0.7 notes:

Extended attributes are lost when symbolic files are restored on UNIX clients.
In particular, the security context extended attributes of symbolic files are also
lost on Security-Enhanced Linux (SELinux) clients.

After performing a single file restore operation on a UNIX client, the following
error can be found under the Task Progress tab of the Backup, Archive, and
Restore interface:

08:19:05 (92.001) attr_set failed for <file_name> - Attribute
security.selinux not set. Errno = 2: No such file or directory

The error occurs when the file is a symbolic link and the target of the symbolic
link no longer exists. Despite the error, the file appears to have restored
successfully. However, the extended attributes of the symbolic link are lost. This
issue applies to both virtual clients and physical clients.

Note: If the target does exist, no error is reported and the extended attributes
will get set on the target instead of the symbolic link.

So, it seems that there is no fix or workaround.