7
2013
Fix: Operating System Error 5 (failed to retrieve text for this error. Reason: 15105). (Microsoft.SQLServer.Smo)
An article by 
When trying to take Microsoft SQL Server database backup to a network shared disk then receiving following error,
Error text: Cannot open backup device “\\xxxxxxxx\xxxx.bak” . Operating System Error 5 (failed to retrieve text for this error. Reason: 15105). (Microsoft.SQLServer.Smo)
The error may vary, you may also receive Operating system error 5(Access denied) and that too for local disk instead of network disk. But symptom is same.
Solution to fix this issue,
1. Go to network share (where the actual folder is shared)
2. Right click and go to “Sharing and Security…” option, click it
3. Go to “Sharing” tab and then click permissions settings,
4. Give Full access privilege to the account which is taking backup (if running under SQL server service account context then give full privileges to the domain account), if you are not much concerned on security for the activity then give full privileges to EVERYONE temporarily and once activity is complete revoke it
5. After adding necessary accounts and privileges, click Apply and OK
6. Now go to “SECURITY” tab, add all accounts to whom you have given access permissions in STEP 4 and give them FULL Control or write privileges as deemed necessary, if not concerned for security then give EVERYONE account full control for the activity and then revoke later
7. Once done click Apply and then OK
8. Now try to take backup, it should happen successfully.
Hope this solves issue!
References:
About the Author: Nitin G
Indian born, trekker, biker, photographer, lover of monsoons. I've been working full time with SQL Server since year 2005 and blogs to post the content aquired during my research on new topics or fixing issues faced by me as a DBA while working in different kind of projects, hope some of my posts may helps others in SQLDBA community. Everything you read on my blog is my own personal opinion and any code is provided "AS-IS" with no warranties!
8 Comments + Add Comment
Leave a comment
Subscribe to this blog via Email
Old Posts
- November 2017 (3)
- October 2017 (4)
- September 2017 (2)
- May 2017 (1)
- April 2017 (1)
- July 2016 (3)
- May 2016 (1)
- April 2016 (1)
- February 2016 (2)
- January 2016 (1)
- October 2015 (1)
- September 2015 (1)
- August 2015 (1)
- July 2015 (2)
- June 2015 (3)
- April 2015 (1)
- March 2015 (1)
- December 2014 (1)
- September 2014 (2)
- April 2014 (1)
- January 2014 (3)
- October 2013 (2)
- September 2013 (2)
- August 2013 (4)
- July 2013 (1)
- June 2013 (2)
- May 2013 (5)
- April 2013 (3)
- March 2013 (1)
- February 2013 (9)
- January 2013 (11)
- December 2012 (14)
- November 2012 (3)
- October 2012 (4)
- July 2012 (2)
- June 2012 (3)
- May 2012 (2)
- April 2012 (8)
- March 2012 (6)
- February 2012 (3)
- January 2012 (1)
- December 2011 (5)
- November 2011 (8)
- October 2011 (5)
- September 2011 (3)
- August 2011 (3)
- July 2011 (3)
- May 2011 (1)
- November 2010 (1)
Tags
Calender
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Nov | ||||||
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 | |||||
View Post by Categories
Recent Articles
- Setting up Always ON Availability Group in Multi Subnet Cluster – Recommendations
- Configuring Replication with Always ON Availability Group
- Login failed for user ‘DOMAIN\COMPUTER$’. Reason: Could not find a login matching the name provided. [CLIENT: ]
- Modern Servicing Model (Service Pack and Cumulative Updates) for SQL Server 2017 and onwards
- Fix: SSMS 2012 opening Debug window when pressing F5
Many thanks for sharing this, it has solved the problem with backing up our database, without having to change the service account being used by SQL server.
Thanks Sangeeta, glad it solved your issue.
Thanks, work in different case, but similiar, thanks a lot.
I had the same error and solved by allocating more space to the destination directory. try that.
Turns out that mine was because the database and backup location were both located on mount points. As soon as the database was mounted from a local location instead of the mount point the backups went through straight away. Cheers
Well tried to explain in short, voted as “yes”. Here this article also described broadly the term SQL Server Error 15105. http://sqltechtips.blogspot.com/2015/12/backup-error-15105.html
I have the same error message but i am not saving to a network share. In fact my SQL DB is stored on a different disk and accessed with a mount point. The backup location is another separate disk accessed with a different mount point.
If i back up to a local disk it works fine. This error only started happening recently and before this it worked fine.
Any ideas?
Thanks 🙂