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

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 - 00:56:50 CDT