MSSQL Backup to a network share fails with an error: Operating system error 5(Access is denied.), how to win?

Question

LDAP

Good afternoon, Khabrovites.

Initial data:
Virtual server on ESXI 5.5
OS:
Windows Server 2019 Std Core x64
SQL server version:
MS SQL Server 2017 x64

From time to time I return to the issue of setting up database backups on a network share, in my sandbox, but I just can’t find a way to win error:

Of course, the domain user has been given the appropriate rights to the network folder, and the MSSQL instance service starts on behalf of this domain user.
Screenshot of the command line executed on the server itself with the mentioned [email protected] instance:

Launch properties of the specified MSSQL instance:

Read the articleabout a similar case, but unfortunately the methods proposed in it did not help to solve the described error.
Please help deal with the situation.
Thanks for taking the time to read.

Answer 1

I'm wildly sorry, but have you tried reading the documentation?
https://docs.microsoft.com/en-us/sql/relational-da...

Answer 2

Good hour Khabrovites.
Issue resolved, but first things first.
Well, firstly:
Congratulations to Sharik, you are a dunce.
The described initial cases were executed on the wrong server, I just mixed up the open connections in the open SSMS, well, no one has yet canceled the stupidity.
Now about possible solutions.
For administration flexibility, I created an access group in Active Directory, and granted rights to the required share.
Option 1.
Added the account of the computer on which the MSSQL instance is running to the access group.
I did not change the username of the MSSQL service launcher, by default it runs from Local System.

The result of performing a database backup with a command in SSMS: Success
The owner of the created backup file on the network share: computer account

Option 2.
Added a domain user account to the access group, changed the user from which the MSSQL instance is launched to the same user.

Result: Success
The owner of the created file on the network share: the account of the domain user specified above.

Z.Y. When granting access using a group, the access consumer is required to relogin to Active Directory. User - logoff, logon; PC - restart. When assigning rights to a share directly, relogin is not required. Somehow I played with a similar case and could not understand why it does not work when everything is assigned correctly.
For the purity of the experiment, the entrance to each of the tested MSSQL instances was performed using local SQL authentication, and of course, such a user did not have access to the network share used.

No. Because SSMS is a client, not a server, and actions are performed on behalf of the client.

So this assumption is probably wrong.
Now it remains to decide what is the right thing to do in the context of security:
Use the PC account to access the share, or use the technological user account of the MSSQL service.
Many thanks to everyone who did not stand aside and took part in the discussion.