FileZilla failing after a macOS update

A site that connected every day for two years now times out. Or the application bounces once in the Dock and quits. Or it connects, shows the remote folder, and then the listing never arrives. The instinct is to reinstall, which fixes almost none of these, and the instinct after that is to blame the last macOS update, which is sometimes right and often not.

The useful move is to separate the failure by where it stops. Four shapes cover nearly everything, and the project's own release notes name the cause of several of them outright, which makes this far less guesswork than it looks.

Separate the failure by where it stops

Shape one: the application does not launch, or it launches and quits. Nothing to do with the server.

Shape two: it launches but no connection is established. The message log stops at the greeting, the login, or the certificate.

Shape three: it connects and authenticates, then the directory listing fails or hangs. This is almost always the data channel, which is a separate connection from the one that just succeeded.

Shape four: everything works and the transferred files are wrong. Truncated, corrupted, or renamed.

Each shape has a different first check. Running through all of them in order wastes an hour. Identifying the shape takes thirty seconds by watching the message log pane at the top of the window.

When the application will not launch

The most recent release exists largely for this case, and it affects a specific group of Mac users rather than everyone.

macOS: Work around a bug in macOS 27 where setting the locale to non-English triggers crashes in AppKit Source: filezilla-project.org

Release 3.71.1 went out on 26 August 2026 carrying that fix. The condition is worth reading twice: the interface language set to anything other than English, on macOS 27. Anyone running the application in Japanese, German, Spanish or any of the other supported languages on a current Mac was hitting a crash inside an Apple framework, not inside FileZilla. Updating to 3.71.1 or later is the fix. Switching the interface to English is the workaround for anyone who cannot update immediately.

Two other launch cases. The minimum supported system is macOS 10.13.2, stated on the download page for both Mac architectures, so a very old machine is simply out of scope. And release 3.70.4 in April 2026 updated the underlying libfilezilla library specifically to address a crash, so a machine still on 3.70.0 through 3.70.3 has a known crash fix waiting for it.

There is also a much older Apple Silicon note worth knowing if an ancient copy is still in place. Release 3.68.1 fixed a build issue affecting notarisation on arm64. Anything predating that on an Apple Silicon Mac is better replaced than diagnosed.

When it launches but will not connect

Here the release notes are unusually candid, because two recent changes were deliberate tightenings that turn a previously working connection into an error.

The first landed in release 3.70.6 in June 2026. The client used to guess the remote path syntax by detecting the server type. That guess was removed, and unusual server types now have to be declared by hand on the advanced page of the site manager. A host that only ever worked because the guess happened to be right will fail after this update, and nothing in the error message points at the setting that now needs filling in.

The second landed in release 3.71.0 in August 2026. On servers set to DOS type, malformed paths used to be accepted and then confuse the engine. They are now rejected early. Better behaviour, and also a change that converts a badly configured host from working to not working.

For SSH File Transfer Protocol connections the picture is different. The whole SFTP layer was rebuilt on a new library in the 3.70 series, and the releases since have been a steady stream of compatibility work against servers that do not follow the specification: updates for servers sending malformed authentication request packets, for invalid bits in file attribute flags, for invalid names in directory listings, and for corrupted uploads. Two of those shipped as something more useful than a fix:

SFTP: Added a page with compatibility flags to the Site Manager Source: filezilla-project.org

That page is where an awkward server gets accommodated per site rather than globally. Anyone whose SFTP host broke somewhere in the 3.70 series should open it before concluding the client is at fault.

A related authentication case explains the loop where the password is typed, accepted, and asked for again. Several releases adjusted how a keyboard-interactive request is handled on servers that do not offer plain password authentication, including a heuristic to answer a single prompt named Password with the stored site password, and an automatic retry when keyboard-interactive authentication fails. Release 3.70.0 separately fixed extra password prompts that appeared when password saving was disabled but passwords were being remembered until the application closed. If the symptom is repeated prompting rather than rejection, updating is the fix rather than a settings change.

When the listing fails after a successful login

This is the shape most often reported as FileZilla not working, and it is the one least likely to be the client's fault. Login uses the control connection. The directory listing uses a second, separate data connection, and that is what a router, a firewall or a VPN interferes with.

The client does try to work around one common case on its own. Release 3.69.2 added a retry from a different source port when establishing a passive mode data connection fails because the address is already in use, which removes a class of intermittent listing failures that used to look random.

Beyond that, the sequence worth following is short. Switch the site between passive and active transfer mode and retry, because one of the two usually works where the other does not. Disconnect any VPN and retry, since a split tunnel will route the control connection and the data connection differently. Confirm the account has permission to list the directory it lands in, rather than only to read files inside it. And read the message log rather than the status bar, because the log carries the server's own reply and the status bar does not.

Two cases that look like an empty or broken server

Two more symptoms get misread as a server problem often enough to list separately.

A folder that opens and appears empty, when it visibly contains items, points at symbolic links. Release 3.70.0 fixed access to symbolic links over SSH File Transfer Protocol, and release 3.70.6 added a compatibility flag for servers that send invalid bits in file attribute flags, which is what makes a client misclassify an entry. A linked directory presented as something other than a directory will not open. Both are addressed by updating, and the second one by setting the flag for that site if it persists.

The certificate dialog is the other. On an FTPS connection the certificate has to be accepted before anything else happens, and if that dialog cannot be read or dismissed, the connection simply never completes. Release 3.69.4 fixed a case where the verification dialog failed to become scrollable on certificates carrying many subject alternative names. Shared hosting certificates routinely list dozens of domains, so this affected exactly the hosts most people connect to. An older build on a shared host is worth updating before anything else is investigated.

Both of these illustrate why the version number is the first thing to establish. A symptom that reads as a server fault, a permissions fault or a network fault has repeatedly turned out to be a fixed defect in a build from a few months earlier, and no amount of adjusting site settings will move it.

When the files arrive wrong

Two verified causes sit behind altered files.

The first is filename handling. Release 3.70.0 made the replacement of invalid characters in downloaded filenames permanent and removed the ability to turn it off. Characters that macOS or the local filesystem will not accept get substituted on the way down. Files therefore arrive with names that do not match the server, by design, and any build step comparing filenames will fail on it.

The second is genuine corruption, and it was a real defect. A release candidate in the 3.70 series updated the SFTP library specifically to address corrupted uploads. Anyone who has been running an early 3.70 build and has seen a damaged archive on the server should update and re-upload rather than hunting for a network cause.

The update prompt that will not go away

A separate symptom deserves its own note, because it looks like a broken updater and is not. The application asks to update, the update is installed, and the next launch asks again.

The official troubleshooting guidance names the cause: more than one copy installed. On macOS the instruction is to look in the Applications folder for more than one FileZilla entry and move the older one to the trash. This happens easily on a Mac, because the distribution is a compressed application bundle dragged into place rather than an installer that replaces what is already there. Two copies with different version numbers, and whichever one launches keeps finding an update.

Checking which build is actually running

One check belongs in every diagnosis on an Apple Silicon Mac, because it costs nothing and quietly affects everything above.

The macOS download page serves the Intel build by default. Its heading states as much, and the file offered is the x86 archive. The native build is published in the same release but appears only after following the link to the additional download options, where it is listed as a separate platform:

FileZilla_3.71.1_macos-arm64.app.tar.bz2 Source: filezilla-project.org

Open the Activity Monitor, add the Kind column, and the answer is immediate. An installation carried forward from an Intel Mac stays on the translated binary through every subsequent update, because nothing in the update path switches architecture. Replacing it is a plain drag and drop, and site definitions are unaffected.

The order to work through

Check the version first and update if it is below 3.71.1, because three of the causes above are already fixed upstream and a fourth is a deliberate change documented in the release notes. Then check for a second copy in the Applications folder, and check the Kind column for an Intel binary on an Apple Silicon machine. Only after those three should the site settings be touched, starting with transfer mode and then the compatibility flags page for an SFTP host.

Every one of those steps means moving between the Finder, an application window and a terminal to check what is actually on disk, which is its own cost on a day already going badly. The features page covers how much of that round trip collapses when the folder view and the shell share one window, and the comparison page for Atriens sets that approach against the transfer clients.