If you are running an on-premise instance of Jive you may occasionally perform a manual data copy or data migration to either prepare for a site upgrade or refresh the data in your test environment.
One issue that you may see is that after doing a data copy users will no longer be able to upload new files or create new documents.
This document outlines a common cause for this issue and a fix for this problem.
End User Issue Symptoms
All file uploads will fail in Jive with the following error message:
"The document is too large."
Server Log Symptoms
Jive recommends that you set the com.jivesoftware.eos.fs.FileStorageProvider class to have INFO level logging in Admin Console: System > Management > Logging Management > Configuration > Logging level override
Logger name: com.jivesoftware.eos.fs.FileStorageProvider
Following the issue being reproduced, you should see the following entry in your sbs.log log file:
2016-03-21 18:09:14,115 [http-nio-127.0.0.1-9001-exec-13] [2000:1111111111:REGULAR] INFO com.jivesoftware.eos.fs.FileStorageProvider - File exists '/apps/opt/jive_binstore/jiveSBS/2/0/7/20711111ydoByranib.bin'.
2016-03-21 18:09:14,116 [http-nio-127.0.0.1-9001-exec-13] [2000:1111111111:REGULAR] ERROR com.jivesoftware.community.impl.binarybody.DefaultBinaryBodyStreamProvider - Could not save binary body for document -1
2016-03-21 18:09:14,118 [http-nio-127.0.0.1-9001-exec-13] [2000:1111111111:REGULAR] ERROR com.jivesoftware.community.content.publish.impl.ContentPublisherImpl - Rolling back transaction after creation failure
If you are seeing these errors in both the frontend of Jive and in the server logs then proceed with the fix outlined below. If you are not seeing these error messages then please create a new support case.
The issue is caused by an administration error performed during the data back up and restoration process when copying data from one Jive instance to another.
Typically Jive will recommend that you configure your site so that all file uploads are stored on the file system binstore instead of the database. When you back up and restore a Jive system you will need to make a copy of both the application database and the file system binstore at the same time, and both of these backups should be restored together.
The issue outlined here can manifest when an application database backup is not restored at the same time as the file system binstore backup, and instead an older application database is restored alongside a newer file system binstore. This mismatch in backups can cause the database and the binstore to become out and sync and prevent new files from being created due to conflicting IDs and files.
You will need to update the record in the jiveid table in your application's database so that Jive is able to generate a new binary file upload ID that is not already being used by a file in your filestorage system.
The fastest way to fix the issue is to increase the jiveid record for binaryBody uploads by a large enough number so that it is unlikely to be conflicting with any existing files. This is the query to increase the binaryBody ID by 5000:
update jiveid set id = id +5000 where idtype=110;
You may need to increase the number by more than 5000 if you have a larger discrepancy between your binary data backup and your application data backup.