SQL Server service accounts are virtual accounts as MSSQL$InstanceName. When a SQL Server instance uses a directory to write data it is necessary that the virtual account has permissions to write in the directory.
Nevertheless, I have a server in which an instance is using a directory without, apparently, having the required permissions on it, altough there are two groups with full permissions: Administrators and System.
How is it possible that the virtual service account writes in the directory? Is a virtual account able to write in any directory in the server?
Related
I'm trying to use an FSx file share as the Backup directory when installing SQL Server Express on my EC2 instance, but the SQL installer fails to use the UNC path to the FSx file share due to a SeSecurityPrivilege problem.
I can access the file share on FSx with full access from the EC2 instance using File Explorer, but do not know how to set the SeSecurityPrivilege as I don't think it is possible to access the File Server for the FSx share as proposed in the error message from the SQL installer below.
Any ideas would be appreciated?
The error is this:
"SQL Server setup account does not have the SeSecurityPrivilege privilege on the specified file server in the path . This privilege is needed in folder security setting action of SQL Server setup program. To grant this privilege, use the Local Security Policy console on this file server to add SQL Server setup account to "Manage auditing and security log" policy. This setting is available in the "User Rights Assignments" section under Local Policies in the Local Security Policy console."
The error indicates that the account used to install SQL server doesn't have the "SeSecurityPrivilege" permission on the FSX servers which is required to perform the installation.
By default, the FSx Delegated Administrators Group has this permission.
You need to add your user account to that group on your FSx Windows File System along with Full control on the share and full control on the ntfs.
The problem is that you connected to this machine with the windows/machine administrative. you should connect to this machine with the Active directory administrative user and follow the below document.
https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/
"a specified logon session does not exist. it may already have been terminated" after i joined the device to azure active directory
-i can't access our shared folder in our server after i joined the device to azure AD and use office 365 account (Please see click the link below to see the error image for your reference), but if i use local administrator of the device i can access the file server using the credentials with no problem, please note that we don't have an premises active directory or GPO, kindly help me.
a specified logon session does not exist. it may already have been terminated
Instead of specifying just "binos" as your username, add hostname with back-slash like so:
yourhostname\binos
In most cases, this will fix that error.
To access the share, the server would also need to be azure ad joined. which you cannot do with windows server, you would need azure ad Domain Services (AD DS) on azure, then join your file server to that.
Only Windows 10 devices can be "azure ad-joined devices"
If you don't want to do that, you could create a azure file store, and secure it using your azure ad / rbac, then map that on your devices.. that would probably work too.
When attempting to create scheduled backups for TFS 2015, I received the following message: "TF401002: The SQL Server Database Engine failed to save the database backup to path \{share}\d$\TFSBackups. Please grant SQL service account read/write access to that folder."
I can't seem to find a solution that will work for me. The 'TFSBackups' folder is shared with full permissions for the NETWORK SERVICE and MSSQLSERVER.
What haven't I done?
Put the comment from Panagiotis Kanavos in the answer.
The error message is crystal clear and has nothing to do with TFS.
That account doesn't have permission to write to that folder.
The path is NOT a path to a valid share, it uses the administrative
endpoint d$ to directly access a physical drive. Only administrators
are allowed to use administrative endpoints.
Just share TFSBackups, set the proper permissions and use the share's
path, eg \\MyStorageMachine\TFSBackups
Normally SQL Service is running at user NT Authority/SQLAgent or similar(these users doesn't have authorization to tfs network folder). Go services and change owner of service to an account which has access to tfs folder.
I had the same problem with TFS, You must be setting up TFS Backups using TFS Admin console.
It is actually the SQL service which write and read backup files to the said location.
Just make sure you grant access to the SQL Service accounts.
If you're on Domain pay attention to Domain User Name.
In my case, SQL Server engine was executed by domain user User#Domain.com but my true permission was for Domain\User so fixing user Logon as in SQL engine saved my day.
Most of the time NT Authority doesn't have write permission on network path so, you need to change Azure or TFS owner user to valid network user.
When trying to run the following database backup command from my code I get an "Operating system error 5(Access is denied.)" error. This is because the log on account for the SQL Server Windows Service is 'Network Service' and that does not have access to right to this folder.
BACKUP DATABASE [AE3DB] TO DISK = 'c:\AE3\backup\AE3DB.bak'
My question is, from my code how would I go about figuring out where on the C drive 'Network Service' is allowed to right the backup to?
NOTE: This is a distributed application so I cannot easily change the log on for the SQL Server Windows Service to the 'Local System' account that would be able to right to that folder.
You don't go about searching for random places on C:\ where the SQL Server service account has write access...
You can choose between:
place the backups in the SQL Server backup location. This is specified during setup and it is properly ACL'ed so that the service account has all the necessary permissions. See 'Backup Directory' in http://msdn.microsoft.com/en-us/library/cc281941.aspx
place the backup in a well known location that you create and you ACLit for proper permissions for the SQL Server service account. You should not grant permission to the service account itself (NETWORK SERVICE in this casE) but instead grant to the SQL Server administrative service group: SQLServerMSSQLUser$ComputerName$MSSQLSERVER. See http://msdn.microsoft.com/en-us/library/ms143504.aspx
The whole point of Network Service account is to not have rights to the local disk. This prevents network based security holes.
My guess is your server is locked down which means you have to log in locally to do a backup or use the administrative account to do so remotely.
I am trying to link an MS access mdb to my sql server 2005, the problem is that the MDB is located on a shared network drive which will require login/password.
How do I pass the username and password into the "Linked server Access MDB" template? I assume I have to #datsrc parameter?
Rather than embedding credentials it would seem more sensible to use existing NT authentication and run the SQL Server service under an account which has access to the network drive. See question 63749 for some useful hints on service account setup. So, either grant permission for the current SQL Server account to be able to access the network drive, or run the service under a different (possibly new) account which has access.