I ran into a similar situation where the TSM client (v5.2.3 at the time) wouldn't backup/restore the ext3 extended acls on RHEL3. The problem turned out to be that the TSM client is looking for libacl.so but couldn't find it. It was available as libacl.so.1 (which symlinked to libacl.so.1.1.0). By adding a symlink for /lib/libacl.so pointing to libacl.so.1 I was able to backup and restore files w/extended acls.
-Ken Mueller -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Dave Mussulman Sent: Tuesday, May 29, 2007 3:15 PM To: ADSM-L@VM.MARIST.EDU Subject: ext2 extended file attributes? One of my users pointed out that ext2 has an extended attribute to tell dump not to back it up. He was wondering if TSM honored that setting. I gave it a try (chattr +d test_file) and then did an incremental backup of the directory. TSM seemed to ignore the no_dump bit and backed up the file, and upon restore, didn't restore the ext2 attributes (they were all blank.) Is this expected? I can understand, perhaps, not honoring the no_dump (since it's not dump,) but I'm a little concerned extended file attributes for ext3 aren't backed up/restored. Is there a special flag or setting I need to define on the client for that behavior? A bug? This is on a 5.3.3 client on a RedHat AS4 system. Dave