Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

CREATE FILE encountered operating system error 5(failed to retrieve text for this error. Reason: 15105)

Ask Question

I have a database file .mdf from MS SQL EXPRESS in folder:

C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\DATA

I would like to attach it to MS 2008 R2 (MSSQL10_50.MSSQLSERVER) but using Server Management Studio I receive the following error:

CREATE FILE encountered operating system error 5(failed to retrieve text for this error. Reason: 15105) while attempting to open or create the physical file

Do you have any idea how to solve it?

Is it possible the mdf is already attached to an instance of SQL Server, or it is open in a Visual Studio project or something along those lines? Have you tried making a copy of the file and attaching that? Where did the MDF file come from? Is it possible it wasn't detached cleanly from its original source? – Aaron Bertrand Jun 24, 2012 at 15:09 Is SQL Server running as administrator? See CREATE FILE encountered operating system error 5 Access is denied – Andomar Jun 24, 2012 at 15:11 Thanks guys for your comments, I was able to solve the issue running as ADMINISTRATOR thanks! – GibboK Jun 24, 2012 at 15:12 The response by stackoverflow.com/users/2029904/user2029904 is much less aggressive and resolves the underlying problem - insufficient access by the instance account to the database file. – Pekka Jul 15, 2013 at 20:29 @GibboK what if database create with EF:Code First? i change my model and when i try to run program this error apear.i run VS as administrator but nothing change – AminM Dec 15, 2016 at 8:26 Fixing "insufficient access by the instance account to the database file" didn't work for me, only running as Administrator worked. Why doesn't one Microsoft programmer fix this once and save us all this unnecessary pain? – tbone Aug 28, 2017 at 21:38

It's a Windows permissions issue. If you connected to your server using Windows Authentication then that Windows user needs permissions to the file. If you connected to your server using SQL Server authentication then the SQL Server instance account (MSSQL$, e.g. MSSQL$SQLEXPRESS) needs permissions to the file. The other solutions suggesting logging in as an administrator essentially accomplish the same thing (with a bit of a sledgehammer :).

If the database file is in your SQL Server's data folder then it should have inherited the user rights for the SQL Server account from that folder so the SQL Server authentication should have worked. I would recommend fixing the SQL Server instance's account's rights for that folder. If the data file is somewhere else and the SQL Server account does not have permissions then you will likely encounter other problems later. Again, the better solution is to fix the SS account rights. Unless you are always going to log in as administrator...

Edit the Security properties for the data folder to include full control for the user running SQL Management Studio. – Suncat2000 Jul 3, 2013 at 3:20 The instance account attempts to open the data and log files with a Write DAC permission. This is available if the <Machine>\Users account has full permission to the files. When the Test connection succeeds, these permissions are overwritten to specific SQL Server values, erasing the temporary settings. – Pekka Jul 15, 2013 at 20:27 Run As Administrator does not work for me. When I check, SQL Server in services, it was running under Network Service account. I give Network Service rights on that folder, and create database is a success :) – Atta H. May 7, 2015 at 15:33 This answer directed me to my solution: Make sure the identity that SQL Server Service is running with (like, "NT Service\MSSQLSERVER"), has access to the DATA folder. – Alejandro Moreno Dec 7, 2015 at 17:46

Start->Run->services.msc->scroll through the list of services until you find SQL Server->right-click->properties->Log On tab:

Then choose Local System Account and check the Allow service to interact with desktop checkbox.

Restart the service.

This resolved the issue for me. Running SQL Server Management Studio as administrator did not solve it for me. – Guru Josh Mar 29, 2015 at 11:37 In contrast to me, I logged in using the SQL Server authentication with the "sa" account and it works. – d.i.joe Oct 16, 2019 at 11:19

I was getting similar error.

CREATE FILE encountered operating system error **32**(failed to retrieve text for this error. Reason: 15105) while attempting to open or create the physical file

I used the following command to attach the database:

EXEC sp_attach_single_file_db @dbname = 'SPDB',
@physname = 'D:\SPDB.mdf'

This same problem occurs when the owners of the file have been deleted. When this happens, if you go to the file's properties, you will see a SID rather than a user name. Take ownership of the file (giving yourself FULL CONTROL). Once that is done you can do whatever you need to do with the file.

I've had this work when logging in as the administrator didn't do the trick.

As other suggested running as administrator will help.

However this only if the windows user is actually an admisnitrator on the machine which sql server runs.

For example when using SSMS from a remote machine it will not help using "run as administartor" if the user is only a administrator on the machine runing SSMS but not on the machine running SQL Server.

1.copy your --.MDF,--.LDF files to pate this location For 2008 server C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA 2.In sql server 2008 use ATTACH and select same location for add

I had this issue on Windows 2003 with SQL 2005. I had to take ownership of the files as my Windows user account and I got the database to attache that way.

You have to right click on the file, select Properties, click OK to get past the information screen, click the Advanced button, select your account from the listing of available accounts or groups, apply that change, and Click OK on the Properties screen. Once you have done all that you will be able to manage the file permissions.

I logged into SSMS with Windows Authentication and I was able to attach the database without error.

Cheers!

If you are already running as an adminstrator, make sure the user you are using has the proper server roles.

  • Login as sa (if you can)
  • Expand the Security folder
  • Expand the Logins Folder
  • Right click on the user you would like to use
  • Select Properties
  • Select Server Roles
  • Select all the server roles
  • Click OK
  • Restart SSMS
  • Login with the modified user
  • In my case I have got the error when trying to create a databae on a new drive. To overcome the problem I created a new folder in that drive and set the user properties Security to full control on it(It may be sufficient to set Modify ). Conclusion: SET the Drive/Folder Properties Security for users to "Modify".

    My solution was slightly more complicated. After verifying the user the service was running as, running MSSMS as local and domain administrator, and checking folder permissions, I was still getting this error. My solution?

    Folder ownership was still maintained by local account.

    Properties > Security > Advanced > Owner > (domain/local user/group SQL services are running as)

    This resolved the issue for me.

    Opening SSMS as Administrator and running as SQL Auth vs Windows Auth did not work.

    What worked was to just change my filename to the same location where the LDF and MDF files are located.

    alter database MyDB
    add file ( name = N'FileStreamName', 
    filename = N'D:\SQL Databases\FileStreamSpace' ) 
    to filegroup DocumentFiles;
    

    I got this error when restoring a database that was backed up on another server. After a long struggle this is what I did

  • Enabled Instant File Initialization,

  • Granted permissions (full control) on the folder to the service account and my own windows account,

  • Restarted the SQL service. Database restored after that.

  • The key is "operating system error 5". Microsoft helpfully list the various error codes and values on their site

    https://msdn.microsoft.com/en-us/library/windows/desktop/ms681382(v=vs.85).aspx

    ERROR_ACCESS_DENIED 5 (0x5) Access is denied.

    copy your --.MDF,--.LDF files to pate this location For 2008 server C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA 2.

    In sql server 2008 use ATTACH and select same location for add

    I don't see this option in my Visual Studio solutions's Configuration Manager. What do you mean? – bkwdesign Jan 31, 2019 at 19:14

    Here is what happened in my case. I was asked to attach files for a database. I was given the file names as follows

  • devdb.mdf and devdb.ldf
  • I proceeded to attach the files and kept getting the files are in use by another process.

    I ran a query against the system view select name, physical_name from sys.master_files; and saw that the exact file names were already in use by another database, thus each time I tried to attach the files, I kept getting the error the files are in use by another process(sql server)

    Thus if you are getting such a message, then also query against the system view sys.master_files and see which database may already be using the same name files. Hereafter you will figure out what to do.

    thanks.

    Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center. – Community Oct 16, 2022 at 13:01

    If facing similar issue in SQL Server running on docker container, fix by granting appropriate permissions to volumes.

  • Login to container as root user

    docker exec -it -u root <container id> bash

  • Grant appropriate permissions to all volumes path e.g. /var/opt/sqlserver/data

    chmod 777 </var/opt/sqlserver/data>

    actually this worked for me, the other option to run Management studio as administrator did not help, but changing file permissions did the trick. And btw - the question was about ideas how to solve the problem - so IMO this is an answer (although not very polished) – Prokurors May 30, 2014 at 16:16 Giving "Everyone" (effectively, this should be read as "every human in the world") permission to mess with your database is hardly a solution, though it may hide the real problem. – Oskar Berggren Jan 22, 2015 at 15:26

    Thanks for contributing an answer to Stack Overflow!

    • Please be sure to answer the question. Provide details and share your research!

    But avoid

    • Asking for help, clarification, or responding to other answers.
    • Making statements based on opinion; back them up with references or personal experience.

    To learn more, see our tips on writing great answers.

  •