The “dolphin file upload error” is the generic error dialog that appears in the KDE file manager Dolphin whenever a file transfer fails. In many cases the dialog is cryptic – it simply says “File upload failed” – and the real problem (network, permission, or a bug) is hidden behind the UI. The error can be triggered by a wide range of conditions: wrong protocol settings, firewall/NAT problems, file‑system permissions, disk‑quota violations, software regressions, or even subtle library incompatibilities.
Because the underlying failure is usually logged by the KIO framework, the first step to a resolution is to enable and examine the KIO log. From that log you can often spot the exact error code (KIO::ERR_COULD_NOT_CONNECT, SSL handshake failed, Permission denied, etc.) and compare it with the server’s own logs. The remaining sections walk you through the typical causes and show how to isolate them one by one.
Common Causes
Below is a short, bullet‑point summary of the most frequent root causes for the dolphin file upload error. These categories should be treated as a checklist when you encounter a transfer failure.
- Network path broken – The control port (FTP 21, SSH 22, SMB 445) is reachable, but the data‑connection port range used by passive FTP or SMB is blocked by a NAT or firewall.
- Protocol mismatch – The server requires an explicit TLS/SSL handshake for FTP or a particular SMB version, but Dolphin is configured for the plain protocol (or vice‑versa).
- File‑system permissions – The target directory is owned by a different user or the ACLs block write access for the client’s account.
- Disk space / quota – The user has exceeded a filesystem or network‑filesystem quota, or the filesystem is mounted read‑only.
- Outdated libraries – A buggy version of libssh2, libcurl, or smbclient is used by the KDE Frameworks that Dolphin depends on.
- Software regressions – Known KDE bug tracker tickets (e.g., 188765, 197342, 205019) describe specific combinations of server configuration and KDE release that cause the error.
Troubleshooting Workflow
The following ordered checklist is designed to help you pinpoint the underlying failure. For each step, the key points to verify are listed explicitly.
- Network connectivity
- Ping the server:
ping -c 4 example.com– look fortimeandttl.
- Ping the server:
- Traceroute to confirm a clear hop path.
- Telnet to the control port (21 for FTP, 22 for SSH) – a successful handshake means the router can see the control channel.
- Test data‑connection ports – for passive FTP forward the
pasvminport‑pasvmaxportrange invsftpd.confthrough the router. - Server side configuration
- Verify passive mode is enabled on the FTP server:
pasv_enable=YESand a valid port range.
- Verify passive mode is enabled on the FTP server:
- Check that the SFTP user’s public key exists in
~/.ssh/authorized_keysand thatsshd_confighasAllowUserspermitting the account. - For WebDAV, confirm the server allows
PUTandPROPPATCHmethods, and that the SSL certificate is not expired. - When TLS/SSL is required, ensure the client side (Dolphin → Settings → Configure Dolphin → Network Settings) requests the same TLS version and cipher suite.
- File permissions
- SSH into the host and run
ls -ld /path/to/directoryto read the mode and owner.
- SSH into the host and run
- If the directory is owned by another user, add the client’s user to the group or grant
+wto others. - On Windows shares, open the “Security” tab in folder properties and confirm that the user has “Write” permission.
- Check ACLs with
getfaclon Linux and adjust withsetfaclif needed. - Disk space / quotas
- Run
df -h /path/to/directory– look forUse %near 100 %.
- Run
- Check the user quota:
quota -u usernameon most Linux distros. If the limit is hit, increase the quota in/etc/fstabor the quota configuration. - For NFS, verify that
quotais enabled on the export and that the client can see the limits. - Client settings
- In Dolphin: Settings → Configure Dolphin → Network Settings, make sure the protocol is set to the same as the server (e.g., “FTP with TLS” if the server is
ftpd -T).
- In Dolphin: Settings → Configure Dolphin → Network Settings, make sure the protocol is set to the same as the server (e.g., “FTP with TLS” if the server is
- Confirm the “remote host” and “remote directory” are typed correctly.
- Use key‑based authentication for SFTP/SSH – change from password to key if you’re hitting login problems.
- Enable KIO log
- Edit
~/.config/kio/globalrcor the equivalent KDE configuration to adddebug=1.
- Edit
- Restart Dolphin (or log out / log in again) so the KIO framework picks up the change.
- Re‑run the failed transfer; the error dialog will now show the raw KIO error string.
- Open the KIO log file (usually
~/.cache/kio/log/xxxx.log) and look for the full error message. Common patterns include:SSL handshake failed– TLS negotiation issue.
Permission denied– file‑system ACL or NFS export permissions.Connection timed out– data‑connection blocked.Quota exceeded– disk‑quota violation.- Compare with server logs
- FTP:
/var/log/vsftpd.logorjournalctl -u vsftpdfor detailed TLS/ACL failures.
- FTP:
- SSH/SFTP:
/var/log/auth.log(orsecure) for key or authentication failures. - SMB:
/var/log/samba/log.smbdfor “Permission denied” or “Operation not permitted” messages. - WebDAV: the web‑server’s access/error logs – look for
403or404before thePUTcall. - Apply known patches or upgrades
- If you see a “WebDAV 403” or “FTP 550” error that matches a KDE bug (e.g., tickets 188765, 197342, 205019), apply the specific patch from the KDE git repo. Example for WebDAV status code exposure:
git apply webdavstatuspatch.diffand rebuild the module.
- If you see a “WebDAV 403” or “FTP 550” error that matches a KDE bug (e.g., tickets 188765, 197342, 205019), apply the specific patch from the KDE git repo. Example for WebDAV status code exposure:
- Upgrade the KDE Frameworks:
sudo apt upgrade kde-frameworksorsudo dnf upgrade kio-*on your distribution. - For Samba, enforce SMB2/SMB3 on the server with
max protocol = SMB2insmb.confand reload the service. - Test the fix
- Do a small file upload to confirm the change worked.
- Repeat with a larger file to ensure quotas or limits are respected.
- If the error re‑appears, revisit the earlier steps; often the problem is a combination rather than a single fault.
Preventive Tips
- Keep your KDE stack (Dolphin, KDE Frameworks, and the underlying libraries) up to date. New releases fix many regression bugs that caused the upload error in older releases.
- Maintain a central, documented permission policy for user accounts on shared directories and network filesystems. This reduces the “Permission denied” surprises.
- Regularly audit disk quotas and free space on all shared volumes.
- Configure your firewall to allow passive data‑connection ports for FTP and the SMB/SMB‑direct port range.
- Use key‑based authentication for SFTP/SSH; it is more robust than password login and eliminates the need for frequent credential changes.
- Schedule periodic test uploads during low‑traffic periods to verify that network, permissions, and quotas remain healthy.
Conclusion
The Dolphin file upload error is not a single bug but a symptom of many possible misconfigurations. By systematically verifying connectivity, protocol settings, permissions, space, and library versions – and by always inspecting the KIO log – you can isolate the real cause and apply a durable fix or patch. The checklist above should help you resolve most failures quickly and keep your file‑transfer workflow smooth.
No comments yet. Be the first to comment!