Debugging issues with the Sync Client

Collecting Client logs

All the available logging options are described in the "Advanced Usage" section of the client logs. The basic options to provide us with insightful, debugging logs are:

• --logwindow - will display the following scrollable "Log Output" window. From there they can be copied, searched and saved.
• --logfile <filename> - will dump those logs on a text file on <filename>.

Notes

There are some platform-specific details worth mentioning at this point.

macOS:

In case you're using macOS, you can manually add a couple of aliases pointing to ownCloud's absolute path to simplify the use of these commands from the CLI:

owncloud=/Applications/owncloud.app/Contents/MacOS/owncloud
owncloudcmd=/Applications/owncloud.app/Contents/MacOS/owncloudcmd

Windows

• You can launch the --logwindow at any time by pressing F12 on your keyboard.
• To include any of the above options on client launch, you can explicitly write the flags down the "Target" textbox of the desktop shortcut:

Network debugging

Since we're dealing with a client application, it's key to gather all the information we're sending and receiving from the server in order to determine which side might be responsible for an issue.

While all erroneous, wrong or unexpected network replies will appear on the client logs we just reviewed. There's quite a lot of information out of their scope that can help us troubleshoot and reproduce the conditions that lead to an issue.

In order to do this, you can use mitmproxy to intercept the client's network activity in detail. You can find installation instructions for your platform on the project website. In a gist, when running mitmproxy on your terminal, you're starting a server daemon on localhost:8080 (if the port is already allocated on your system - use -p/--port to specify a different one) that will act as network proxy. This can be set easily on the client's Network tab, under the Proxy Settings section:

• Switch to Specify proxy manually as... + HTTP(S) proxy
• Host 127.0.0.1 : 8080

After setting up the proxy between your ownCloud and the client, you'll need to manually accept its self-signed certificate so it can begin to intercept all traffic:

Here you can see how an mitmproxy invocation and an account setup from the client looks like on a bash session:

Notes

• If you happen to have a self-signed, expired or any other kind, you'll need to pass the --insecure flag to mitmproxy so it ignores the issues when authenticating the upstream certificate.
• All the requests sent to localhost will not pass through the proxy. If both ownCloud and your client are located on the same host, use your full hostname or any DNS record to connect both. Otherwise, your requests will not appear on mitmproxy.
• If you're using Windows cmd, there are some well known limitations for TUIs. You can replace it by mitmweb (the web UI version of the CLI tool) or use the mitmproxy official docker image.

Alternatives to mitmproxy

If you don't happen to like TUIs or you would rather use a different tool, you can also try the powerful wireshark to filter your client's traffic. Or some paid alternative like fiddler or charles proxy for instance.