I recently configured a SharePoint 2013 Standard environment for a customer who required RBS for a video streaming service they wanted to build in SharePoint and I came across the following errors.
This is an array of errors I got depending on the site template (2010 vs. 2013) or what service I tried to write with, such as using Windows Explorer or using the Upload Document web interface.
Architecture
The architecture of this SharePoint environment was quite simple as you can see below.
- SharePoint 2013 Standard
- SQL Server 2012 Standard
- RBS (FileStream)
All of this lives on the same physical server.
Symptoms
After having configured the SharePoint 2013 content database to use RBS as prescribed in the very useful instructions HERE, the end user gets the above error messages. Most often, the message states something similar to the below message.
Sorry, something went wrong
The URL ‘Shared Documents/filename.docx’ is invalid. It may refer to a nonexistent file or folder, or refer to a valid file or folder that is not within the current Web.
You will find later, that this error is not very helpful.
No new documents can be uploaded or created, and existing documents cannot be edited or removed.
Troubleshooting Attempts
I spent and inordinate amount of time troubleshooting this issue. Google searches of the error turned up little useful information. The most common articles I found typically were related to folks that could write small files under 1MB but anything larger wouldn’t write. That wasn’t helpful as I couldn’t write anything.
Checking the BLOB file location and it appeared that I had RBS setup right as the folder was created.
Resolution
It turns out the issue was a permissions issue (as I had expected). It was a SQL permissions issue with the Web Applications service account.
I found that when I added the service account to the db_owner role on the content database, all of a sudden I could write to the site with new files, modify existing files and even delete files. Even the RBS portion was working just fine writing to the BLOB store.
Long story short, here are the instructions to manually add your service account for the web application to the db_owner role on the content database.
- Open SQL Server Management Studio
- Expand the Database folder
- Expand the specific content database you’ve configured for RBS
- Expand the Security folder
- Expand the Roles folder
- Double click db_owner (see below)
- In the Role Members section click the Add button (see below)
- Select the Web Application Service Account and click OK
- Click OK until you have returned to the screen from step 6 above
- You should now be able to write to your RBS enabled Content Database
I searched the web for quite some time and found no articles that was experiencing this issue so perhaps it was just a fluke. At first, I thought it was because I pre-created my content databases, but I did try letting SharePoint create the content database through the Add Content Database menu in Central Administration but I had the same issue.
I hope if you are experiencing this issue you find this article and it helps quicker than it took me to find the solution.
TechChucker's Brain Blast 
I had the same exact problem. It must be a glitch with the RBS install package. Thank you for posting your finding!
Hope my post helped. When I deploy SharePoint we have to limit our permissions for our Farm admin in SQL so we don’t get to have SysAdmin on the Instance. This means we often have issues from time to time when we go to install or configure parts of our SharePoint. That was why we were having a permissions issue. My guess is if you simply have SysAdmin for your Farm Admin and you let SharePoint create your databases then you may not run into this issue. I could be wrong. It’s been a while since I’ve installed SharePoint letting the wizard create all my databases.
Thanks for stopping by. Again, I hope the article helped. Have you experienced the KB2844286 issue on your system that’s going on right now?
Thanks so much for posting this. I am having the same issue and was really frustrated looking out for solutions. I will try this workaround.
I hope this solves the issue you’re having. Let me know if it does. I’ve setup RBS several times and every time I’ve had issues it’s always come down to permissions on the DB.
Thank You for the article it helped me to solve the problem.
Awesome! Glad it helped.
Hi,
Myself I’ve installed and configure RBS (correctly) in Sharepoint 2013 but doesn’t work.
It didn’t put any file in File System (BLOB Storage).
Any idea why?
Other people seems to have the same issue:
http://social.technet.microsoft.com/Forums/exchange/en-US/e279451f-fe02-4e9f-8e97-30290bdbdc35/rbs-with-sharepoint-2013-and-sql-2012-almost-working?prof=required
Thanks
Grig
I’ve found the majority of times I’ve had issues with RBS configuration it’s due to some permissions somewhere not being correct. Your issue may be permissions, but it may also be something simpler. When you setup your BLOB storage configuration, did you manually create the “Blob Storage” directory or did you let the configuration process create it? If I remember correctly, you need to let it create the final directory manually otherwise it won’t work. You might also verify your SQL service account has Full Control of the directory so it can write to it. I hope that helps. If not, if you can find some events in your event viewer to provide I may be able to help more.
Hi,
Thank you for your message.
The size is 1048576 = 1M
I’ve uploaded all kind of file size until 1.5G but it didn’ go to BLOB folder. It went to content db.
The WebApplication identity has rights to write also in the content DB also in this BLOB folder.
$rbss = $cdb.RemoteBlobStorageSettings
$rbss
Enabled ActiveProviderName MinimumBlobStorageS UpgradedPersistedPr
ize operties
——- —————— ——————- ——————-
True FilestreamProvid… 1048576 {}
So everything seems to be ok but is not putting the file in BLOB store.
It should work. I did it before. I don`t know why is not working this time.
Thanks
Grig
It helped me as a beginner, I just add all account that can access the sharepoint web application. And it worked… Thank you 🙂
Nuts… Thanks for the tip… I wasted most of the morning on this one. I find this really puzzling that this needs to be done manually. Talk about a needle in a haystack. I also don’t appreciate granting db_owner privs to an account like this.
Yeah, it’d be nice if it were automatically set.
As far as giving db_owner privs to the DB. I come from a different perspective. I believe the way we manage SQL needs to change for vended applications in which the DB architecture is dictated by the vended application. Mean, if you’re not building DB’s why do you want to manage the DB the way you do all of your other DB’s? If you change your support model for applications like SharePoint and most other Microsoft applications so now you are only supporting the SQL Server Hardware and SQL Server services, then you can put more of the responsibility of ensuring the integrity of the DB’s to the Application owners. This means, your application owners must have a certain level of expertise as a DBA, though quite possibly not as much as you might think. You as the System Admin of SQL can still manage all the maintenance jobs like backups etc, but when it comes to permissions management, allow the application owner to dictate (to a certain degree) the levels for each account (no sysadmin of course, though not entirely a horrible idea if they have a dedicated SQL Instance).
The reasoning for this shift is that SharePoint and other applications themselves are managing more of the Database than your traditional homegrown applications. The role of the SQL System Admin/DBA can be split if it’s not already. Most microsoft applications like SharePoint explicitly prohibit the actual modification of their databases beyond just permissions so there’s no reason to need someone to go poking around in those DB’s to do anything but permissions. If you have a good plan from the start, you can set it and forget it.
We ran into so many problems with our SQL folks trying to fit SharePoint into the same templates they had been managing all their other SQL customers into that we had performance issues, and connectivity issues and all sorts of other issues. Settings would change on us and all of a sudden our data storage was full because they kept trying to change our Log databases from SIMPLE to Full.
So as scary and as uncomfortable as it may seem to a SQL guy/girl, in order to have a technically sound SharePoint deployment, you either need to make some concessions or become a SharePoint administration expert and become the SharePoint application owner as well. Which do you prefer? 🙂