Troubleshooting add/checkin upload failures

A collection of information about Vault, including solutions to common problems.

Moderator: SourceGear

Post Reply
Posts: 1821
Joined: Thu Dec 18, 2003 11:39 am
Location: Sourcegear

Troubleshooting add/checkin upload failures

Post by jeremy_sg » Wed Apr 07, 2004 9:04 am

Some users encounter a situation where they can log in to Vault, and all repository operations work, except for Add File and Checkin. The cause of this failure is almost always solved by the following steps.

Look at the Messages pane in the GUI client, or the Output pane in the IDE client.
Often the error message given is key to determining the cause of the failure.

Common error messages are:
  • "The Vault server could not be contacted to perform the operation. Your network connection to the server may have been interrupted."
    "Could not apply the delta."
    "Chunked encoding upload is not supported on the HTTP/1.0 protocol."
    "Upload for item failed, retrying..."
    "Upload for item failed too many times, aborting transaction"
    "This request requires buffering of data for authentication or redirection to be successful."
    "The server had an error processing the file upload but did not return an error header"
Change the Vault setting that controls advanced HTTP features
For most users, the cause of this problem lies in the fact that Vault uses the HTTP 1.1 feature ChunkedEncoding to save memory usage. Certain proxies, firewalls and routers cannot accept HTTP 1.1 features, so the Vault client must be configured to use only HTTP 1.0 features. For instructions on disabling ChunkedEncoding, see

Personal Firewall
In some cases, firewall software (such as Norton Firewall) will prevent the transfer of a file because it thinks it might be a virus, and this will reveal itself in Vault as a specific file not being added or updated correctly, where other file adds/updates do work.

Check the log file
You may see lines that say “XML stored procedures are not supported in fibers mode”. This indicates there may be a problem with the configuration of the SQL server hosting the sgvault database. See this KB article for a fix:

Check Web Service impersonation permissions
If your Vault Web Service is configured to use impersonation, verify that the account has permissions to the Vault temp directory (C:\WINDOWS\TEMP by default) and the account's temp directory (C:\Documents and Settings\Account.DOMAIN\Local Settings\Temp). Also verify that the account had "Log on locally" permissions to the server, to enforce that the account's temp directory exists.

Verify that IIS is set up to allow anonymous access
For other users, the cause of the problem is in IIS settings. It is important that the VaultService virtual directory on the IIS machine have anonymous access enabled. In order to verify that anonymous access is enabled, bring up the Internet Information Services tool under Administrative Tools. Right click on the VaultService virtual directory, and choose Properties. In the Properties dialog, choose the Directory Security tab and click on the Edit button in the Anonymous access and authentication control area. In the resulting dialog, verify that Anonymous access is checked.
anonaccess.GIF (94.45 KiB) Viewed 13935 times

Post Reply