The user will need the following rights:
Backup Files
Restore Files
Manage Auditing and Security Logs

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Darby, Mark
Sent: Thursday, January 26, 2006 4:22 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: NT Privilege problem


A user is getting "ANS4974E a required NT privilege is not held."
messages when they attempt to ARCHIVE a file through the TSM client
Archive GUI.  The TSM client is a Windows 5.3.2.0 (i.e., the client that
was on the ftp site under the \maintenance\ path as of yesterday) and is
running on Windows XP Pro SP2 (32-bit).

The following may also provide additional information pertinent to this
problem:
1. The user may NOT necessarily have the same (if any) permissions to
the higher-level directories in the path to the file in question.
2. The user can open the file in question using Notepad.
3. The file in question resides on a file share (i.e., on a mapped
network drive).
4. The problem occurs even though the environment of the TSM client is
exactly the same as the one in which the file is successfully opened
using notepad - i.e, from the same machine and logged in and running
under the same credentials.
5. The user can successfully archive files from their local drive(s).
6. The user authenticates to one domain and the file-server (NAS) on
which the "problem file" resides is part of another domain.
7. The domain to which they authenticate may be (because I don't know)
serviced by an NT 4.0 domain controller while the NAS is definitely part
of an Active Directory.
8. There are "trusts" set up between these domains (of some sort) - I'm
not a Windows expert.
9. The user must be able to perform the archive operation(s) themselves
(ad hoc) without sysadmin support involvement.

I believe the TSM client is attempting to archive the complete directory
structure above the file in question, as well as the file itself and,
given the permissions they do NOT have to those upper-level directories,
is failing as a result.  This would at least explain the symptoms they
are seeing.

Will someone please comment on my suspicion (confirm/refute) and/or
offer a solution that will not entail changing NTFS permission(s) on the
upper-level directories?

Regards,
Mark