This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(44.800000000000004, 26%, 14%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EC%3C/text%3E%3C/svg%3E)
Greetings. So we're currently in the process of moving in to another data center, and at the same time moving from physical clusters in to VM's. On several of these clusters our sysadmins have failed all SQL instances to one node, nuked the cluster, then did a physical to virtual move with mostly success.
However, last night we attempted this and all DB's were good except one w filestream enabled. Effectively FS didn't make the trip.
I was able to enable/ disable FS as expected using sp_configure and doing it through Configuration Manager, but attempting to do anything beyond basic enabling like configure the Windows share name would result in the attached.
Also had similar to this in the SQL log.
Error: 5105, Severity: 16, State: 14.
A file activation error occurred. The physical file name <file path> may be incorrect. Diagnose and correct additional errors, and retry the operation.
The folder structure was intact and the permissions were as expected.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(240, 3%, 33%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EG%3C/text%3E%3C/svg%3E)
Check if your SQL server is a 32-bit on a 64-bit Windows. If that is case, you may get that error.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(108.80000000000001, 46%, 20%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EAM%3C/text%3E%3C/svg%3E)
Hi @chrisrdba ,
Could you please check if the SQL Server service account have permission to the physical file?
In addition, what the version of SQL Server are you using? Have you installed the latest Service Pack or cumulative update for SQL Server?
Best Regards,
Amelia
If the answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
By physical file I assume you mean the folder that houses the filestream data? Yes the account has perms there.
Unfortunately this is an old 2012 box.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(192, 23%, 28%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJW%3C/text%3E%3C/svg%3E)
Did you enable FILESTREAM on the new instance?
I use the old Error Lookup utility to look up the error code in your screenshot. I got this result: *There are no more endpoints available from the endpoint mapper. * Unfortunately, I have very little idea what this implies.
On this server where you are having this problem, have you restored any databases with filestream?
You say that you are moving to VMs. Is the disk area where the filestream area resides local to the VM?
For troubleshooting, you could try to create a new database with filestream, and see if you can get that one going.
You said this was an old 2012 box - I guess you mean Windows Server 2012, but if you are moving to VMs, why such an old OS? Or is it SQL Server 2012?
This would be the first DB with FS.
Not sure what you mean by "local to the VM"? It's a VM so not sure what the options are.
Yes I've tried to create a new DB. All the files made it in the P2V so I'm just trying to attach those to another DB and getting the message:
Msg 5591, Level 16, State 5, Line 9
FILESTREAM feature is disabled.
Msg 5105, Level 16, State 14, Line 9
A file activation error occurred. The physical file name 'P:\myFolder' may be incorrect. Diagnose and correct additional errors, and retry the operation.
Msg 1813, Level 16, State 2, Line 9
Could not open new database 'FileStreamDB'. CREATE DATABASE is aborted.
The question about "local to the VM" was not a very good one. I was thinking of local vs. mounted, but this is a cluster, that's a pointless question.
I don't have much ideas, but did you try to create a database in that location, that is directly on the P: drive?
It could be something in your file system does that does not play well with filestream, but I don't know what.
Thanks Erland -- note that this WAS a cluster, now it's a VM
Filestream puts a folder where it needs to and then permissions it to the SQL Server service account. Then the file folder is under the control of SQL Server so all the files and file structure works inside SQL.
Going from Cluster to Standalone could have disrupted the folder structure. You can check and see where the folder is if you restore filelistonly for the backup of that database. Ensure that the sql server service account has permissions on that folder structure.
Typically moving Filestream to another server by virtue of Copy or in this case a volume move, users and permissions are key to getting this hooked back up again.
Does this help? You would need to enable filestream from the SQL Configuration Manager as well as in the engine too.
The file structures match between the source and destination.
The SQL Server service account has full control on all folders related to FS.
FS is enabled in the SSMS GUI, and on the service in SS Config Manager, and even the Registry has an enableValue of 2. A restart and reboot have been done since verifying all of this.
However, it's worth noting that despite all of this, running sp_configure shows a run_value of 0. I've set it to 2, done a restart, and still it shows 0.
Have you checked the SQL Server errorlog for any error messages?
By the way, is P:\MyFolder authentic? It would be a little odd I think to create the filestream area directly on the top of the disk. Then again, if the OS does not really agree to having filestream being activated, I guess the path does not matter.
Beside the SQL Server errorlog, have you looked in the WIndows event log to see if there is anything that seems relevant?
There has to be something up.
SS Configuration Manager -> Open Services and open properties on the SQL instance and in the Filestream tab, check all of the check boxes and choose a share name (usually the instancename with MSSQLSERVER being the default instance)
Restart the instance only
Check it again. If it sticks then you can check the sp_configure and it should have 2.
Then you go into the database and ensure that the Filestream is enabled on the database.
If you cannot get that setup, then there is something wrong indeed.
Nothing of use in the log or EV.
No it's not authentic -- I'm paranoid about putting anything identifying online, though the folder structure is probably a but much. In fact I just realized I should have put some additional info in my original post and will now -- I'll even get a little crazy and put the real paths. I have attached the explanation, due to the silly 1000 character limit that makes it impossible to post much of anything.
When I try to modify from there I get the error that I originally posted in the .pdf
Yes, that is definitely a problem. Is the server name the same as it was in the cluster?
Do you get the real name of the server if you do SELECT @@SERVERNAME
I can understand that you anonymise names. The problem with too much simplification is that it can introduce false concerns.
I look at your command, and I see that you are creating the database FOR ATTACH. Personally, I prefer to always move databases with BACKUP/RESTORE. If you do it this way, you may have to think about permissions in the file system. If you use RESTORE you don't have to worry.
What happens if you try to create a completely new database with FILESTREAM?
Sorry I just noticed this. The instance names are the same yes.
