************************************************************************************************
* Description: DB failed to start with access denied error due to files on Windows shared drive
* Date: 05:02 PM EST, 08/07/2017
************************************************************************************************


<1> Symptom:
     |
     |__ o. Oracle database built-up based on Windows platform, and control file, data file, and redo logs are stored on NAS shared drive.
            When database startup, following errors are show up:
	 
	 
                 ORA-27040: database can not startup, due to cannot read control file 'N:\fast_recovery_area\controlfile\control.ctl'
                 OSD-04002: unable to open file 
                 O/S-Error: (OS 5) Access is denied. 
					 
					 
					 
<2> Cause:
     |
     |__ o. For Windows OS, oracle.exe process long-running execution is based on Windows service.
     |       If current login user does not have the permission to access the network attached shared drive or network resource, and then failed to read control file to startup database.
     |
     |		
     |__ o. Simply speading, each Windows service executes in the security context of a user account, which is called Windows Service User Accounts. 
     |      Each account type defines what permissions this service have, and what level resource this service can access according to the account type.
     |      In this case, Oracle db_service must be owned by an user in an account type, called "Network_Service" to access the shared drive.
     |
     |
     |__ o. Following are Windows Service Account Type, more detail:
         |
         |__ 1) Domain User Account
             2) Local User Account
             3) Local System
             4) Local Service account
             5) Network Service account
	 
             
	


	

<3> Solution:
     |
     |__ o. CMD 
            => services.msc 
            => Right click "OracleServieDatabase" 
            => "Properties" 
            => "Log on" 
            => "This account"
            => Submit the credential who has the network shared drive access. 
            => Restart Service
      			 
			 

			 
<4> Reference:		
     |
     |__ o. https://serverfault.com/questions/771059/what-does-log-on-as-a-service-actually-mean
     |
     |__ o. After changing service owner under"This account" of the Windows service, syste will alert "The account .\username has been granted the Log On As A Service right".
     |
     |__ o. The "Log on as a service user right" allows accounts to start network services or services that run continuously on a computer, even when no one is logged on to the console.
     |
     |__ o. In short, you only want to provide this right to the accounts that need it - 
            by default, that's the Local System, Local Service and Network Service accounts, because those are what services run under by default.

            If you wish to run a service under a different security context (like a service account you create), you would want to grant that service account Log on as a Service rights 
            so that it could run your service without the need for a user to be logged in. 
            The article you link provides IIS and ASP.NET as examples where additional accounts are granted this right; 
            it applies to third-party programs that run as services as well.

            If you don't want to run every service as SYSTEM or NetworkService, you would setup service accounts for individual services and assign them this Log on as a Service right. 
            The main advantage of using service accounts in this way is that if your service is compromised, it's running under the security context of the account running it, 
            rather than the SYSTEM-level security context that SYSTEM and NetworkService have.