Re: RMAN won't write to mapped drive under Windows

Paul,

Thank you very much for the detailed and informative response. I'm using RMAN with 9.2.0.4. Normally I use RMAN to dump to disk and have the network backup come around and pick up the files later on. Getting RMAN to dump directly to tape looks like a pain. I changed all the Oracle Services to log on as Domain Admin but this doesn't work ...

run {

   backup

      format '\\servername\sharename$\foldername\%U'
      database plus archivelog delete input;

With RMAN 9i, I know the RUN {} is not needed in this case, but it seems to me RMAN just can't write to a remote machine under Windows like this. I think I'm going to log a TAR with Oracle to see if it is possible.

Thanks again,

Domenic.
drak0nian_at_yahoo.com (Paul Drake) wrote in message news:<1ac7c7b3.0309232156.3fe01451_at_posting.google.com>...
> domenicg_at_hotmail.com (Domenic G.) wrote in message news:<c7e08a19.0309231549.2c59823d_at_posting.google.com>...
> > Assume x: is a mapped network drive under Windows 2000/XP with full
> > r/w permissions ...
> >
> > run
> > {
> > allocate channel ch1 device type disk format 'x:\orabkup\b_%U';
> > backup database plus archivelog delete input;
> > }
> >
> > Why does RMAN report an OS error? -- to the OS x: looks like it's
> > local. Anybody know? Without using tape, I want to get the backups
> > onto another machine with a mirrored drive.
> >
> > Domenic.
>
> Domenic,
>
> You did not report oracle version info here. That is usually highly
> significant.
> Please post that and others might respond in a helpful fashion.
>
> When you are logged into a desktop (console) as your user account, be
> it a local or domain account, your console session is running under
> your credentials.
>
> If you accept the defaults, and run the "OracleService%ORACLE_SID%" as
> LocalSystem, that account has no rights off of the local machine.
>
> Can you imagine how widespread the damage would be, if a single
> (win32) machine that was compromised had admin rights to other win32
> boxen as LocalSystem?
>
> Sealed for your protection.
>
> In a domain environment, if a domain controller is compromised, the
> offending code (e.g. worm, Nimda comes to mind) can traverse the
> admin$ shares of every machine belonging to the domain, infecting
> every box in that domain. Fortunately, things are slightly more secure
> now than then, but mostly due to the compromises that occurred in the
> past, and people not wanting to lose the mail servers, domain
> controllers, etc. EVER AGAIN.
>
> So, I would recommend that you examine what security token the oracle
> instance (oracle.exe) and rman process are running as. If they are
> running as a domain account that belongs to a local ORA_DBA group
> (Pete Finnegan, feel free to shoot this one) that has access rights on
> the network, chances are, you won't receive the error. I've run
> standby code over NetBIOS using batch jobs running as network
> (domain) accounts that moves files between servers without error.
>
> Back before Nimda, we even had a domain ORA_DBA group that was godlike
> over every oracle database in the domain, in which the domain group
> ORA_DBA had been added to the local ORA_DBA group. Mighty convenient.
> Very bad idea.
>
> You *can* open permissions sufficiently to get this to work.
> The question is - do you want to?
> Another question would be, what are the implications of opening shares
> that wide open. Do you care if others have access to those database
> backups?
> Its not difficult to create a password file and init file to open a
> backup set as a clone.
>
> Proposal:
> Why not stage your RMAN backups to local disk - and -
> configure access permissions to the staging area for network (domain)
> backup service accounts to be able to read/list/exec the files
> (or the compressed files, if you have cpu cycles to burn)
> and let your local jobs run locally?
>
> OR -
>
> use a domain account to perform the file copy operation from local
> staging to network storage.
>
> In case you've missed the point of the above text, here it is real
> simple:
>
> 1. that "local" mapped drive is not local.
> 2. localsystem has no privs on the network.
>
> Paul
Received on Wed Sep 24 2003 - 13:41:41 CDT