Cyberduck SFTP remote rename/move fails on FAT/msdos external volume although command-line sftp rename works

[stevenjstromer]

Description:

Cyberduck fails to complete basic remote rename/move operations over SFTP when the target directory is located on an external volume mounted by macOS as a FAT/msdos-style filesystem. The same operations succeed using command-line sftp against the same server, same account, same directory, and same files.

This appears to be related to Cyberduck’s SFTP rename/move behavior triggering a server-side hard-link operation. The underlying filesystem does not support hard links, so the operation fails. Cyberduck does not appear to fall back to a plain SFTP rename or copy/delete operation, and the failure is not clearly surfaced to the user.

To Reproduce:

1. Connect with Cyberduck over SFTP to a macOS OpenSSH SFTP server.
2. Navigate to a directory located on an external volume mounted as msdos / FAT-style, with noowners.
3. Create or locate a test file in that directory.
4. In Cyberduck, attempt either of the following:
   • Rename the file.
   • Drag the file into a subfolder within the same SFTP browser window.
5. The operation appears to issue SFTP RENAME operations, but the file remains in its original location/name.

Expected behavior:

Cyberduck should complete the same basic remote rename/move operation that command-line sftp completes successfully. If Cyberduck’s preferred operation is unsupported by the server or filesystem, Cyberduck should either fall back to a compatible operation or display a clear error explaining the failed operation.

Observed behavior:

Cyberduck does not rename or move the file. The file remains unchanged on the server.

Cyberduck transcript logging showed repeated RENAME operations during the failed rename/move attempts:

Cyberduck: (libcore.dylib) [ch.sudo.cyberduck:transcript] 109 RENAME
Cyberduck: (libcore.dylib) [ch.sudo.cyberduck:transcript] 110 RENAME
Cyberduck: (libcore.dylib) [ch.sudo.cyberduck:transcript] 115 RENAME
Cyberduck: (libcore.dylib) [ch.sudo.cyberduck:transcript] 116 RENAME
Cyberduck: (libcore.dylib) [ch.sudo.cyberduck:transcript] 117 RENAME

Server-side filesystem tracing with fs_usage showed that the OpenSSH sftp-server process attempted a hard-link operation during Cyberduck’s rename attempt:

lstat64 /Volumes/EXTERNAL_VOLUME/Example Folder/__sftp_debug_test/cyberduck_rename_me.txt sftp-server
link [45] /Volumes/EXTERNAL_VOLUME/Example Folder/__sftp_debug_test/cyberduck_rename_me.txt sftp-server

Error 45 corresponds to an unsupported operation. A direct hard-link test on the same volume confirms that hard links are not supported:

ln: /Volumes/EXTERNAL_VOLUME/Example Folder/__sftp_debug_test/direct_link_dest.txt: Operation not supported
exit status: 1

However, command-line sftp can successfully perform the same basic remote rename/move operations in the same directory:

sftp> cd "/Volumes/EXTERNAL_VOLUME/Example Folder/__sftp_debug_test"
sftp> put /etc/hosts cli_sftp_test_upload.txt
sftp> rename cli_sftp_test_upload.txt cli_sftp_test_renamed.txt
sftp> mkdir cli_sftp_test_dir
sftp> rename cli_sftp_test_renamed.txt cli_sftp_test_dir/cli_sftp_test_moved.txt
sftp> rename cli_sftp_test_dir/cli_sftp_test_moved.txt cli_sftp_test_back.txt
sftp> rm cli_sftp_test_back.txt
sftp> rmdir cli_sftp_test_dir

Those command-line SFTP operations completed successfully.

Additional local tests on the server also succeeded:

touch file
mv file renamed_file
mv renamed_file subfolder/
mv subfolder/renamed_file file_back
rm file_back

This suggests that the server, account, path, and filesystem can support ordinary rename/move semantics, but Cyberduck’s SFTP implementation is triggering a less compatible operation path involving hard links.

Filesystem / mount details:

/dev/diskXsY on /Volumes/EXTERNAL_VOLUME (msdos, local, nodev, nosuid, noowners)

Directory listings show synthetic broad permissions typical of this kind of mount:

-rwxrwxrwx 1 user staff file.txt
drwxrwxrwx 1 user staff folder

Cyberduck settings during test:

Preferences → Transfers → General
Transfer files: Open multiple connections
Upload with temporary filename: unchecked
Uploads → Existing files: Overwrite
Downloads → Existing files: Prompt

Important note: “Upload with temporary filename” was already disabled during testing, so the issue does not appear to be caused by that setting.

Desktop:

OS: macOS 26
Cyberduck Version: 9.4.1 (44384)
Protocol: SFTP
Server: macOS OpenSSH SFTP server
Target storage: external FAT/msdos-style volume mounted with noowners

Additional context:

The failure occurs in a normal Cyberduck SFTP session, not through any third-party wrapper or launcher. The operation being attempted is basic remote file management inside the Cyberduck browser window, not a local Finder drag, not a sync operation, and not a special upload workflow.

The underlying FAT/msdos volume does not support hard links, but command-line SFTP proves that ordinary SFTP rename/move can still work in this location. Cyberduck should ideally use the compatible operation or provide a fallback/error message when its chosen operation is unsupported.