ShareX FTP Upload Failed: How to Fix Connection and Permission Errors

When a ShareX FTP upload fails, the underlying cause usually falls into one of four categories: ShareX cannot reach the server, the server rejects the login, the account cannot write to the selected remote directory, or the upload succeeds but ShareX generates the wrong public URL. These problems can look similar inside a screenshot workflow, so changing random settings often creates more confusion. The fastest approach is to identify the exact stage that fails, test one controlled upload, and stop changing settings as soon as that stage works.

This guide applies to FTP, FTPS, and SFTP destinations configured in ShareX on Windows. It covers timeouts, authentication failures, TLS certificate warnings, permission errors, missing remote folders, uploads that land in the wrong directory, and links that return a 404 response. Before sharing screenshots of your configuration or error messages, always hide passwords, private keys, usernames, hostnames, API tokens, and other credentials.

1. Confirm the Symptom and Reproduce It With a Simple Test

Start by separating a connection or login failure from a remote path, permission, or URL failure. These require different fixes. If ShareX cannot connect, changing the public URL will accomplish nothing. If the file reaches the server, changing the password or firewall rules is usually unnecessary.

1.1 Run a small manual upload

Create a small, harmless test file such as sharex-test.txt. In ShareX, use the destination testing option if one is available in the FTP destination settings, or upload the file through the relevant upload command. Avoid testing with a large screen recording because its size can introduce unrelated timeout, storage, or server-limit problems.

Observe exactly what happens:

• Immediate connection refusal: The host, port, protocol, server availability, or firewall is probably responsible.
• Connection timeout: ShareX cannot complete the network connection or the FTP data connection is being blocked.
• Authentication failure: The username, password, private key, authentication method, or account status is wrong.
• TLS or certificate error: The encrypted FTP connection cannot validate or negotiate the server certificate.
• Permission denied: Login succeeded, but the account cannot write to the requested directory.
• Directory not found: The configured path does not exist, or ShareX is starting from a different account home directory than expected.
• Upload succeeds but the link fails: The remote directory and public URL path do not map to the same location.

Success at this stage means the small file uploads and appears on the server. If that happens, stop changing connection and authentication settings. Move directly to checking the generated URL or the original file-specific workflow.

1.2 Determine whether the failure affects every upload

Try one small text file and one small image. If both fail identically, focus on the destination configuration. If small files work but long recordings fail, investigate upload limits, timeouts, available server storage, file size restrictions, or connection stability. If manual uploads work but automatic screenshot uploads fail, review the after-capture and after-upload tasks rather than rebuilding the FTP connection.

2. Check the ShareX Settings Directly Related to This Problem

Open the ShareX destination settings and inspect the FTP account used by the current workflow. Confirm that ShareX is actually using this destination. A correct account will not help if the active image, text, or file uploader points somewhere else.

2.1 Verify the host, port, and protocol

The host field should normally contain a hostname such as ftp.example.com or an IP address. Do not place a public web URL, an upload directory, or an https:// prefix in the host field unless the interface explicitly requests a URL.

Use the protocol and port supplied by the hosting provider or server administrator. Common defaults are:

• FTP: Port 21, normally unencrypted unless upgraded with explicit TLS.
• Explicit FTPS: Commonly port 21, with TLS negotiated after connecting.
• Implicit FTPS: Commonly port 990, with TLS used from the beginning.
• SFTP: Commonly port 22, using SSH rather than FTP.

These are defaults, not guarantees. A provider may use a custom port. SFTP is not FTP with a security checkbox, and FTPS is not SFTP. Selecting SFTP for an FTPS server, or choosing implicit FTPS when the server expects explicit FTPS, will prevent a successful connection even when the username and password are correct.

Success means ShareX reaches the server and proceeds to authentication. Once the error changes from a timeout or connection refusal to a login or path error, the network and protocol layer is at least partly working. Do not keep switching protocols at that point.

2.2 Re-enter the username and authentication details

Copy the exact FTP or SFTP username from the hosting control panel. Some services require a full username that resembles an email address, while others add an account prefix. Confirm there are no leading or trailing spaces.

For password authentication, re-enter the password rather than assuming the saved value is current. If the provider recently rotated credentials, update ShareX. For SFTP key authentication, confirm that the selected private key belongs to the public key installed for that server account. The key may also require a passphrase. Do not confuse an SSH private key passphrase with the server account password.

If the login succeeds in another client but fails in ShareX, compare the protocol, port, username format, authentication method, and key selection. Never post a screenshot showing a password or private key. Crop the image, cover the field, or replace sensitive values before asking for help.

2.3 Check passive mode for FTP and FTPS

Traditional FTP uses separate control and data connections. Passive mode asks the server to provide a port for the data connection, which generally works better for users behind routers, NAT, and Windows firewalls. A connection can therefore log in successfully but hang while listing a directory or transferring a file if the data connection cannot be established.

If ShareX offers a passive mode option for the selected FTP configuration, use the mode recommended by the server provider. Passive mode is commonly the correct choice for desktop users. However, it also depends on the server advertising reachable passive ports and allowing them through its firewall.

Success means ShareX can list or access the destination directory and transfer the test file, not merely authenticate. If another normal FTP client also stalls at directory listing or transfer, the server's passive port configuration or a network firewall is a stronger suspect than ShareX.

2.4 Treat TLS certificate warnings as security errors

An FTPS certificate warning may indicate an expired certificate, a hostname mismatch, an untrusted issuer, or interception by security software. Verify that the configured hostname matches the certificate and the hostname provided by your service. Connecting by IP address can cause a mismatch when the certificate is issued to a domain name.

Do not permanently disable certificate validation merely to remove the warning. Ask the server administrator to renew or correctly install the certificate when appropriate. If a workplace proxy or security product inspects TLS traffic, consult the administrator before trusting a replacement certificate.

Success means ShareX establishes the encrypted session without an unexpected warning. Stop changing certificate settings once the correct hostname and a valid certificate work.

3. Check Windows, Network, Permissions, and Destination Factors

3.1 Compare the result with a normal FTP client

Configure a reputable desktop client with the same host, port, protocol, username, authentication method, and remote directory. FileZilla can test FTP and FTPS, while WinSCP can test FTP, FTPS, and SFTP. This comparison helps determine whether the problem is specific to ShareX.

• If the other client cannot connect, investigate the server, protocol, credentials, firewall, or network.
• If it connects but cannot upload, investigate directory ownership, permissions, quotas, or server policies.
• If it uploads successfully, compare its working directory and connection options with ShareX.
• If both clients upload successfully, focus on ShareX task selection, destination selection, filename handling, and URL formatting.

Do not copy credentials into an unfamiliar online testing website. FTP and SFTP credentials should only be entered into software and services you trust.

3.2 Check Windows Firewall and security software

If the connection times out, test whether Windows Firewall or third-party security software is blocking ShareX. Check whether ShareX is allowed for the network profile currently in use. Corporate networks, public Wi-Fi, VPNs, and endpoint security products may block FTP data connections or nonstandard SSH ports.

A useful test is to retry from a trusted alternative network, such as a permitted mobile hotspot. If the same configuration works there, the original network policy is likely involved. Do not disable the firewall for routine use. Create the narrowest necessary application or port rule, or ask the network administrator to approve the connection.

3.3 Verify remote directory permissions

A successful login does not guarantee upload permission. FTP and SFTP accounts can be restricted to specific directories. In the normal client, navigate to the exact directory configured in ShareX and try to create, upload, rename, and delete a harmless test file if your policy allows it.

A permission-denied response may mean the account lacks write access, the target directory belongs to another system user, the server is read-only, a quota has been reached, or uploads are prohibited in that location. On managed hosting, use the control panel or contact support to grant the FTP account access to the intended directory.

Success means the same account can write a file to the exact destination directory. Once that works outside ShareX, avoid changing the password or protocol. Match ShareX's path to the verified directory instead.

3.4 Distinguish the remote path from the public URL path

The remote upload path is a filesystem or account-relative location used by FTP or SFTP. The public URL is the web address copied after the upload. They may describe the same file through completely different prefixes.

For example, a hosting account might upload into /public_html/screenshots/ while the public file appears at https://example.com/screenshots/file.png. The text public_html belongs in the remote path but not in the public URL. On another server, the login may already start inside public_html, so entering it again would create or target the wrong path.

Use the normal client to identify the account's starting directory and locate the website's document root. Then upload a uniquely named test file and verify its exact public URL in a browser. Configure ShareX so that its remote path reaches that directory and its URL field produces the matching web address.

Success means the generated ShareX link opens the exact uploaded file. If the file is already on the server but the link returns 404, do not change connection settings. Correct the public URL mapping.

3.5 Decide whether folders should be created automatically

If the remote path includes date-based or custom subfolders, ShareX may need to create directories before uploading. Folder creation can fail even when file uploads to an existing directory are allowed. Some accounts have write permission for files but not permission to create directories.

For diagnosis, pre-create the target folder with a hosting control panel or normal client, then point ShareX directly to it. If uploads begin working, the problem is folder creation rather than authentication. You can keep the folder pre-created, simplify the path, or ask the administrator for directory-creation permission.

4. Run a Clean Temporary Test With Minimal ShareX Settings

Create a temporary FTP destination or carefully record the existing values before simplifying them. Use only the confirmed host, port, protocol, username, authentication details, and one known writable directory. Remove date folders, nested paths, custom filename patterns, and complex URL replacements during this test.

1. Choose a short filename such as sharex-test.png.
2. Upload to an existing writable directory.
3. Use the provider's confirmed connection protocol and port.
4. Enable passive mode when required for FTP or FTPS.
5. Temporarily use a simple public URL prefix that maps directly to the directory.
6. Upload once and verify the file in both the normal client and a browser.

If the minimal test succeeds, add one feature back at a time. First restore the desired remote subdirectory, then the public URL format, then filename or date variables, and finally automatic workflow tasks. Test after every change. The first change that breaks the upload identifies the relevant setting.

If the minimal test fails in both ShareX and another client, stop modifying ShareX. Resolve the server, network, account, or permission issue first. If the minimal test works in the other client but not ShareX, verify that ShareX is using the same destination account and review its error output.

5. Check Task History, Logs, and Recent Workflow Output

Open ShareX's history, task list, or debugging information after reproducing the failure. The most useful message is usually the first specific protocol or server error, not a later generic notification that the upload failed.

Look for wording associated with these categories:

• Host not found or connection refused: Check the hostname, port, DNS, protocol, and server availability.
• Timed out: Check the network, firewall, passive data connection, VPN, and server responsiveness.
• Authentication failed: Check the username, password, SSH key, passphrase, and account status.
• Certificate validation failed: Check the FTPS hostname, certificate validity, and trust chain.
• No such file or directory: Check the remote starting directory and whether required folders exist.
• Permission denied or access denied: Check write and folder-creation rights.
• Upload completed but URL is invalid: Correct the URL prefix or path replacement.

Review the most recent task rather than an older failure, and reproduce the problem only once before reading the output. Redact credentials and private host details before sharing logs. A successful result is a completed upload followed by a URL that resolves to the uploaded file.

6. Quick Fix Checklist

• Confirm whether the failure occurs during connection, login, transfer, or URL generation.
• Verify the hostname without an accidental web URL prefix or directory suffix.
• Use the provider's exact port and distinguish FTP, explicit FTPS, implicit FTPS, and SFTP.
• Re-enter the username and password, or select the correct SFTP private key and passphrase.
• Use passive mode for FTP or FTPS when required by the network and server.
• Resolve TLS certificate warnings instead of blindly disabling validation.
• Test the same account in FileZilla, WinSCP, or another trusted client.
• Confirm the account can write to the exact remote directory.
• Pre-create required folders if automatic directory creation is denied.
• Map the remote directory to the correct public web URL.
• Test with a small file and minimal path before restoring automation.
• Stop changing connection settings once the test file reaches the server.
• Never expose passwords, private keys, tokens, or full credentials in screenshots or logs.

7. Frequently Asked Questions

7.1 Why does ShareX log in but time out during the upload?

FTP uses separate control and data connections. Authentication can succeed over the control connection while a firewall, router, VPN, or incorrectly configured passive port range blocks the data connection. Enable the appropriate passive mode, test with another trusted FTP client, and ask the server administrator to verify its passive ports and firewall configuration.

7.2 Why does the upload succeed but the ShareX link return 404?

The remote path and public URL are probably not aligned. Confirm where the file physically lands, identify the web-accessible directory that contains it, and build the public URL from that location. Do not include server-only folders such as a hosting document-root name unless they genuinely appear in the public URL.

7.3 Can SFTP use the same port and settings as FTPS?

Not usually. SFTP runs over SSH and commonly uses port 22. FTPS is FTP protected by TLS and commonly uses port 21 for explicit FTPS or port 990 for implicit FTPS. The server provider must tell you which service is enabled. Choosing the wrong protocol cannot be fixed by changing only the password.

7.4 Why can I upload files but not create a dated folder?

The account may have permission to write inside an existing directory but not create new directories. Pre-create the folder and test again. If that works, remove dynamic folders from the ShareX path or ask the administrator to grant directory-creation permission.

7.5 What should I do if ShareX is not working but WinSCP or FileZilla works?

Compare the working client's protocol, port, encryption mode, passive setting, username format, authentication method, and starting directory with ShareX. Also confirm that ShareX's active uploader points to the account you edited. Then run a minimal upload without nested folders or custom URL transformations.

7.6 When should I stop troubleshooting ShareX?

Stop changing ShareX connection settings when another client also fails with the same account, directory, and network. That result points to the server, credentials, permissions, firewall, or hosting configuration. Conversely, once ShareX uploads the file successfully, stop changing the protocol and login settings. Troubleshoot only the remote location, generated URL, or automatic workflow that remains incorrect.