OK - another stab in the dark Any filenames too long for the filesystem and the API that is handling the files - as in the 250 (approx max) for normal windows 'stuff' That one used to get me (ages ago) when files with long names had been moved, and their foldernames made more user-understandable by changing them from the 11 chars (8.3) to something with the users full name and location.
Other possibility - access restrictions, or MFT corruption such that names of files returned by a 'directory' listing are not actually accessible. Both are reminiscent of dealing with wild piglets - well hidden and you'll have to get down and root around in the muck to find and deal with them. And then you'll get attacked by their 'owners' for interfering with them! JimB -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Kurt Buff Sent: Tuesday, September 15, 2015 8:35 PM To: ntsysadm Subject: Re: [NTSysADM] DPM 2012 error on one job The tape robot is good, and none of the media are write-protected. I should have mentioned that this tape job shares a tape with several other small tape jobs. We have 2 rather large tape writes (Exchange and the file server) that get their own tapes, and several much smaller that are co-located on tape. Kurt On Tue, Sep 15, 2015 at 10:25 AM, James Button <[email protected]> wrote: > My first checks would be for write enabled - > Media - Protect clip, toggle, whatever > Logically - Device Manager - no ? or yellowing of the device's icon > And then Physically - 'Protect' or Write Enable' switch > > JimB > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Kurt Buff > Sent: Tuesday, September 15, 2015 6:11 PM > To: ntsysadm > Subject: [NTSysADM] DPM 2012 error on one job > > All, > > Last weekend, all of my DPM jobs that write to tape worked, except > one. It failed, and keeps failing, with this error: > > The operation failed because of a protection agent failure. > (ID 998 Details: The parameter is incorrect (0x80070057)) > > My SFTW only shows references to problems with SP1 UR3, that it's > resolved with a more current UR, but we're well past that - current as > a matter of fact, at 4.1.3465.0. > > Retrying only generates the same error. > > We're running DPM on server 2008R2. The backup that failed (which I > don't think has happened before, but I've just taken over backups for > a departed staff member) is of a Win2003R2 VM running on VMware 5.5. > > This is actually pretty minor, because this is a machine that isn't > critical, but I'd like to understand it. > > Has anyone run into this and solved it, or perhaps can point me in the > right direction? > > Thanks, > > Kurt > > > >
