Skip to main content
Code42 Support

Web restore troubleshooting tips

Applies to:
  • Code42 CrashPlan (previously CrashPlan PROe)


This article presents several tips for troubleshooting failures during web restore (restores performed through the administration console). These troubleshooting tips apply to single-server and multi-server environments. Follow these troubleshooting suggestions in the order presented.


Required connectivity

Single-server environments

  • From the client browser initiating the web restore to the master server on TCP 4280 (HTTP) OR
  • From the client browser initiating the web restore to the master server on TCP 4285 (HTTPS)

Multi-server private cloud environments

In addition to the requirements for a single server, performing a web restore from an archive that resides on a storage server requires the following:

  • The master server and the storage server must be configured with the same SSL access requirement (under Settings > Security).
  • The web browser for the client initiating the web restore must be able to connect to the master server and the storage server. Web restore fails if a connection cannot be made to the master server or to the storage server that holds the archive.

Though not required, installing a CA-signed SSL certificate on all servers minimizes web restore browser-related issues.

Code42 CrashPlan hybrid environments

  • Performing a web restore from an archive stored on the Code42 cloud requires SSL for all connections. The master server browser connection must be established on TCP 4285 so that the subsequent connections to the Code42 cloud are SSL-grade.
  • Web restores cannot be performed when logged in as the default admin user (has a userId of 1). Log in as another user with administrative privileges to perform a web restore in a hybrid Code42 environment.

Code42 CrashPlan cloud environments

When performing web restore from an archive that resides at the Code42 cloud, the client browser performing the web restore must be able to connect to the Code42 cloud on TCP 4285.

The request is initiated by the client browser. However, if the client-side firewall blocks client-initiated communication on TCP 4285, the web restore pane does not display. Generally, this occurs only in the most restrictive firewall situations, as most firewalls allow client-initiated requests.


1. Validate the configuration

Verify that the website protocol, host and port settings are configured correctly for all Code42 servers in your environment, including all storage servers.

In standard configuration, the website port is TCP 4280 (HTTP) or TCP 4285 (HTTPS).

If the master server is configured to use a private IP or a local hostname and a web restore is initiated from an endpoint with an external address, the restore will fail due to the client's inability to connect to the master server. The same requirement applies to any storage servers in the destination used by the endpoint. In a multi-server scenario, the master server and the storage servers require unique connections from the browser that is initiating the web restore.

Note for servers configured to use a private IP or hostname: The web restore will fail if you attempt to initiate a web restore from an external address.

When attempting to restore an archive located on a storage server, test the connection from your location by pointing your browser directly at the storage server.

2. Test connectivity

Several ports must be configured correctly for Code42 CrashPlan web restore to operate.

Often, software firewalls on the client-side are the root cause of connection failures. For example, a push restore to a CrashPlan app device requires in-bound access on port 4282. A standard Windows workstation with Windows Firewall enabled does not permit this operation and push restore fails. A telnet or browser connection test will confirm this.

Via telnet

You can use the command line utility telnet to confirm that each entity (master server, storage server, client browser) can connect to each other as required.

Via browser

Test the connection from the client system by pointing a web browser directly at the server's website, host, and port address. A successful browser connection displays a sign-in screen.

3. Try TCP 4280

If you are connecting to your master server over the SSL-based port TCP 4285 and web restore fails, try it with port 4280. Some browsers handle SSL issues more severely than others, so remove SSL from the equation. Perform this test if the master server hosts the storage in the destination (that is, a private cloud deployment). If a storage server is involved, see the next section.

Note: If your security settings require SSL to access the administration console, first clear the SSL checkbox.

4. HTTPS/SSL with Firefox

If you do not use a CA-signed SSL certificate for your Code42 servers and you are using Firefox to perform the web restore (via HTTPS), end users must add an exception for the site in their browser configuration before attempting a web restore. Most browsers prompt the user for proper handling of a self-signed SSL certificate; however, Firefox does not.

5. Try another browser

Web browsers handle issues with web restore differently, especially when multi-server connections are required. If web restore fails in one browser, it may work in another. At a minimum, try Google Chrome and the latest version of the native OS-based browser: IE (Windows) or Safari (Mac).

6. Stay current

Verify that you are running the latest version of Code42 server on your master server and all storage server.