The short version
Find your message in the table at the top of the section for the app you were using, or use the page search. Most failures have one of three causes: the other person is not there, a network blocks a direct connection and no relay is available, or a link or room code was already used. Nothing resumes. Files that arrived whole are kept, and a new transfer starts again from the first file. If you have no message at all and the transfer simply never starts, begin with The transfer never starts. This page covers the messages people meet most. Four other pages hold the complete table for their own area:In the browser
These appear on floe.one, or on a self-hosted web app. The label at the top left of the transfer card reads Send or Receive, which tells you which page you are on. Most messages are a red banner inside the card, and its X closes it without retrying anything. Some are the status line under the share link instead, and the entry says so. A web app that someone hosts themselves can run an older version, where a few of these messages read differently: see What an older web app shows.“Open in your browser”
A full-screen card in place of the page. Floe is running inside another app’s built-in browser, an in-app browser such as the one in Facebook, Instagram, or TikTok, and those handle file transfers poorly. Until you leave it or continue, the page has not joined the room, so nothing is lost by switching. Follow the two steps on screen, or tap Copy link to paste in browser and open the link in Chrome, Safari, Edge, or Firefox. The link is also shown on the card: if the copy fails, the card says “Couldn’t copy. Press and hold the link above to copy it.” Continue anyway (some features may not work) carries on where you are. See Receiving files. A request link, one with/r/ in it, is the exception. There the card says to open the link in
current Chrome or Edge on a computer, which is where request links are supported. Under it, a box
titled “To use this phone instead” gives the steps to open the link in your phone’s own browser.
Copy link to paste in browser and Continue anyway work as they do for a share link. See
Sending through a request link.
The transfer never starts
Usually no error appears: both sides sit and wait. Both people have to be present at the same time, and the connection is made directly between the two devices, so three things can hold it up.- The sender left. Closing the browser tab, quitting Floe Desktop, or stopping
floe sendends the session, and nothing resumes it. A browser that opens the link afterward says “The sender is not connected”. - The recipient has not answered. In the browser and in Floe Desktop a transfer starts by
itself once both sides are connected.
floe receiveasks first, with anAccept? [Y/n]prompt. The sender waits 2 minutes for that answer, and-yskips the prompt. - The network allows no direct path, and no relay is available. The two devices cannot reach
each other directly, and the fallback that passes the data through a server is off or missing.
In the browser that fallback is the sender’s
Network relay fallback checkbox, checked by default. A
recipient in the browser has no such control. On the CLI it means nobody
passed
--no-relay. Floe Desktop has no control for it and uses the relay whenever the server offers one.
floe and Floe Desktop stop after 30 seconds of
trying to connect. If the badge at the top right of the card reads Offline,
start with The badge stays on Offline.
The badge stays on Offline
On either page, with no banner. The badge at the top right of the card reads Offline beside a red dot, where it should read Ready. The page cannot reach Floe’s signaling server: your network or a browser extension blocks it, or the server is down. The page you send from still shows a share link after 3 seconds, but that link works only once the badge reads Ready. Someone who opens it before then reads “The sender is not connected”. Try another network, or turn off extensions that block requests, then reload the page. On your own server, see The browser cannot connect to my signaling server.The link opens a page that asks for files
You opened a link someone sent you, and the card’s label reads Send, with an area to drop files. The link lost its end, the part from the# on, which some chat and mail apps cut off. Without it the
page cannot tell which transfer you meant, so it opens as a new send. That is a link from floe. A
link from the web app or Floe Desktop that lost the same part shows “Link Invalid”.
Ask the sender to send the link again, and copy all of it, including everything after the # sign.
“Link Invalid”
A card in place of the transfer on the page you receive on. It reads “This link is incomplete, already in use, or locked to the networks that first used it.” and has a Back to Home button. Three things produce it:- Someone is already connected on this link, including you in another tab. A room takes one sender and one receiver.
- The link was cut short or altered, so the room id or the link key in it
is no longer complete. That includes a link cut at its
&, a link key that lost itsk=, and a link from the web app or Floe Desktop that lost everything from the#on. - The device is on a third network. Once a sender and a receiver on two different networks have started connecting, the room turns away a device from any other network. That catches a phone that moved from Wi-Fi to mobile data. See A device that changed networks is refused.
“Floe couldn’t confirm who sent this link”
On the page you receive on, as a red banner: “Floe couldn’t confirm who sent this link, so nothing was received. Ask them for a new link.” The link holds a link key, and the side that connected did not prove it holds the same one. Its proof was wrong, a file came ahead of the proof, it said nothing for 30 seconds, or it stopped because it could not confirm your page. Nothing was received, and no file’s name reached the page. The line does not say who is at fault. A link damaged on its way to you reads the same as a server stepping in between. A sender’s page does not wait for the proof, so it can read “All Files Sent!” at this moment. Tell the sender what you saw, and if their screen says the files were sent, assume someone else has them. See What the link key checks. The message stays once it shows. Losing the connection to the server, or someone else opening the link, does not clear it, and the page does not go back to waiting. Ask for a new link, over another channel if you can.“Floe couldn’t confirm the person who opened your link”
On the page you send from, as a red banner: “Floe couldn’t confirm the person who opened your link, so nothing was sent. Make a new link and send it again.” The other side sent a proof of the link key, and it was wrong. Your page stopped before any file’s bytes went. The first file’s name and size can have gone, because this page does not wait for the proof before it names a file. The message stays once it shows, and the page takes no new connection on this link. Reload, add the files again, and share the new link. See What the link key checks.“The other side couldn’t confirm this link”
On the page you send from, as a red banner: “The other side couldn’t confirm this link, so nothing was sent. Make a new link and send it again.” The other side holds the link key, and it refused your page’s proof, often because its copy of the link was changed on the way. After the other side has answered a file, the same stop reads “The other side rejected the transfer.” instead, because a file may have gone by then. Reload, add the files again, and share the new link.“This browser can’t check this link”
On either page, as a red banner, and on a request link’s page as a card. The browser could not read the connection’s certificates, so it cannot check the link key. It says nothing about the other side, and a new link would not help. No file’s bytes moved. From the page you send from, the first file’s name and size can have gone. The sentence depends on the page:
Do what the sentence says, in another browser.
“The sender is not connected”
On the page you receive on, as the second step of the card, with “Keep this page open if they are coming back. Otherwise ask them for a new link.” under it. Your page reached Floe’s server and found nobody on the sending side of this link. Usually one of these happened:- The sender closed their page or app.
- Their device is asleep or offline.
- Their connection to the server dropped before the two devices connected.
- The link is from a transfer that already ended.
floe send or Floe Desktop does not come back, because those senders never
rejoin a room. Neither does a browser link whose transfer already finished.
If nothing changes after a minute or two, reload the page once. If it still says this, ask the
sender for a new link.
One case still reads “Waiting for the sender to start” with nobody there: another browser already
has the same link open. The server tells the second page that someone is in the room, and the page
cannot tell that it is not the sender. If you opened the link in two tabs or on two devices, close
one and reload the other.
A device that changed networks is refused
This one has no message of its own. It happens when your phone switches from Wi-Fi to mobile data, or your laptop’s VPN connects, while a transfer is connecting. Once a sender and a receiver on two different networks have started connecting, the room accepts nobody from a third network for as long as it exists. That keeps a stranger who holds the link from taking a place that was left empty. A device whose network changes comes back with a new address, so it counts as that third network.
See How a transfer works.
“Too many refreshes. Reconnecting”
On either page. The server refused this page’s connection because your network address made too many connections within a minute, or has too many open at once. Repeated reloads, many open tabs, or many people behind one address can each do it. That is the server’s rate limit, or its cap on open connections. The page retries by itself, a few seconds apart at first and then up to a minute apart, and the banner goes away once a retry gets through. Wait a minute without reloading, because every reload opens another connection, and close Floe tabs you no longer need. If it keeps happening on your own server, see 429, or “Rate limit exceeded”.“Connection failed. Ask the sender to try again.”
On the page you receive on, as a red banner: “Connection failed. Ask the sender to try again. If they turned the relay off, ask them to leave it on.” The two devices lost, or never found, a network path to each other before any file had finished arriving. The usual reason is that no direct path exists and no relay was on offer: the sender unchecked Network relay fallback, ranfloe send --no-relay, or uses a server that has no
relay. A sender whose device went to sleep or lost its network ends the same way: see
A device that sleeps ends the transfer. So
does one who pressed Ctrl+C in floe send 1.11.0 or earlier. The relay is not always the
culprit.
Ask the sender to start a new transfer, with the relay left on if they had turned it off, then
open the new link.
“Connection failed. This link was made with Network relay fallback off.”
On the page you send from, as a red banner: “Connection failed. This link was made with Network relay fallback off. Reload the page, add the files again, leave it on, and share the new link.” It appears only when Network relay fallback was unchecked. Either the only path that came up was a relayed one, and Floe closed it rather than send over a route you excluded, or the connection failed for another reason while the box was unchecked. In the first case the other side is told why. Reload the page, add the files again, leave Network relay fallback checked, and share the new link.“Connection lost. The other device may have closed the tab.”
On the page you send from. The recipient joined, and then the connection to them failed or closed before the transfer started. That can happen while the page is still connecting, or while it waits for them to take a file. Usually they closed the tab or lost their network, or the two devices never found a path to each other. A no at the prompt offloe receive 1.11.0 or earlier ends the
same way.
Keep the page open and ask the recipient to open the same link again. Your page builds a fresh
connection when they rejoin from the same network. If it fails the same way again, see
The transfer never starts.
“Peer disconnected. Waiting for reconnection”
On the page you send from, as the status line under the share link. The recipient, the peer, had joined and then dropped off the server before the connection between the two devices was up. Closing or reloading the tab does that, and so does a network blip. The link still works: when the recipient’s page rejoins, or they open the link again, your page builds a fresh connection by itself. The same line also replaces “Connection interrupted” when a recipient closes their page partway through a file. A red banner then reads “The connection closed before the transfer finished.” Nothing resumes: when they open the link again, your page sends every file from the start. The page does not recover by itself in these cases:- The sender is
floe sendor Floe Desktop, which end the transfer as soon as the other side leaves. - The recipient comes back on a new network, which the room refuses.
- A file has already arrived in full. The recipient’s page then no longer rejoins by itself, so a connection that drops ends the transfer.
“Reconnecting to your link”
On the page you send from, as the status line under the share link. Your page lost its connection to Floe’s server and came back, and the server would not yet put it back in its own room. The room looked full: usually the page’s old connection had not been cleared yet, which can take up to about 45 seconds, and a recipient had already opened the link. The page tries again by itself for about a minute, and the status goes back to “Waiting for peer” once it is in. You do not need to do anything, and the recipient can keep their page open.“This link stopped working”
On the page you send from, in a red banner: “This link stopped working. Reload the page, add the files again, and share the new link.” The status reads “Link stopped working”. It follows about a minute of “Reconnecting to your link”: the server kept refusing to put your page back in its own room. Either two other devices hold the link, or the room is closed to new networks and your device came back on a different one. Do what the banner says: reload the page, add the files again, create a new link and share that one. Do not rely on the old link.“Transfer blocked. Relay limit exceeded.”
On the page you send from, as the status line under the share link, with an amber notice that starts “Transfer limit exceeded.” The connection turned out to be relayed: the two devices could not connect directly, so the data would have gone through a relay server, which takes 2 GB per transfer at most. Your files total more than that, so nothing was sent. The file count beside the list shows the cap next to your total, for example3 · 2.4 GB / 2 GB.
The receiving page is told why: “Transfer blocked: relay connections are capped at 2 GB. Ask the
sender to send 2 GB or less, or to try a network that allows a direct connection.”
Start a new transfer with 2 GB or less in it, or from a network that connects directly, where Floe
sets no limit. The file list is locked once a link exists, so either way means reloading the page
and adding the files again, as the notice says. See File size limits.
“Transfer timed out waiting for receiver. Please try again.”
On the page you send from. Your page announced a file and the other side did not take it within 2 minutes. The usual cause is a recipient onfloe receive who did not answer its Accept? [Y/n]
prompt in time. A connection that died without closing looks the same. The page then stops and
tells the other side: “The sender stopped after waiting 2 minutes for this device to answer. Ask
them to send again.”
Keep the page open. Ask the recipient to be ready, then to open the same link again: your page
starts the transfer over when they join. On floe receive, -y accepts without asking, and the
link works where the code no longer does.
“The sender ended the transfer before it finished.”
On the page you receive on, when the connection to the sender closed before any file was complete. A second wording, “The sender ended the transfer. Ask them to start it again.”, appears when the browser reports that the sender’s side aborted the connection. Either way the sender’s side closed the connection: they closed or reloaded the tab, canceled or quit in Floe Desktop, or theirfloe send stopped with an error.
A sender whose device went to sleep or lost its network closes nothing. That reads as
“Connection failed. Ask the sender to try again.”
instead.
A sender that stops on purpose says why, and the banner shows its reason. These are the ones you
are likely to see:
Files that arrived before it stay in the list. A stop that comes after every file has arrived
changes nothing: the page still reads as complete. When some files had already arrived and the
connection simply ended, with no stop message, there is no red banner. The page shows
how far the transfer got instead.
Save any files that did arrive, then ask the sender to start a new transfer for the rest. Nothing
resumes.
“Received 1 of 3 files. The transfer ended before the rest arrived.”
On the page you receive on, in amber under the file list, with your own numbers in it. The connection ended after at least one file had arrived and before every file the sender announced had. The line names no cause on purpose, because several look the same from here: the sender closed their page or app, their device went to sleep, or a network failed on either side. When there is a known reason, a red banner above the list carries it as well. The files that arrived are whole and stay in the list, and the file that was arriving is gone. Save what arrived, then ask the sender to send the rest in a new transfer. Nothing resumes. When a device went to sleep, see A device that sleeps ends the transfer.“The connection closed before the transfer finished.”
On the page you send from, after at least one file had started moving. The status reads “Connection interrupted”, or “Peer disconnected. Waiting for reconnection” once the page hears that the recipient left. The connection to the receiving side ended before everything was sent, and they gave no reason: they closed the tab, their device went to sleep or lost its network, or their browser stopped the receive. Your own device going to sleep, such as a laptop whose lid you closed, reads the same once it wakes: see A device that sleeps ends the transfer. If the status changes to “Connection interrupted” after it already read “All Files Sent!”, with no banner, every file had been sent, and the connection to the other device was lost afterward. Ask the recipient what arrived, then start a new transfer for the rest. Nothing resumes.“Could not read” and a file’s name
On the page you send from, as a red banner with the file’s name in it:Banner
“Incomplete file”: a file did not appear at all
On the page you receive on: a file the sender chose is missing from the list, usually under a red banner like this one, with the file’s name and sizes in it:Banner
“A file did not match what was sent, so it was discarded. Ask the sender to try again.”
The sender’s app works out each file’s SHA-256 and the receiving side checks it. When the two differ, Floe discards the file rather than hand you a damaged copy, and the transfer stops. Files that arrived before it are fine. Three messages come from this check:
A file that was still being written on the sender’s side while a browser sent it, such as a
download in progress, can fail this way. Have the sender wait until it stops changing.
“This browser ran out of memory while receiving”
On the page you receive on: “This browser ran out of memory while receiving, so the transfer was stopped. Receive large files on a computer with Floe Desktop (Windows) or the Floe CLI, which save straight to disk.” The browser could not hold any more of the transfer, so Floe stopped it and let go of the file that was arriving. Files that had already finished stay in the list. How much a browser can hold depends on the browser and the device: see Known limitations. This is the message of Firefox, Safari and every browser on iPhone and iPad, which keep every file in memory. In Chrome and Edge the limit that comes first is their own storage, and the page says it ran out of room instead. Save the files that finished, then receive the rest with Floe Desktop orfloe receive, which
write to disk as the bytes arrive. On a phone, where neither runs, ask the sender for the rest in
smaller separate transfers. A single file that is too large for the phone has to go to a computer:
see Known limitations.
“This browser ran out of room for the files it is receiving”
On the page you receive on, in Chrome, Edge, or another browser built on Chromium: “This browser ran out of room for the files it is receiving, so the transfer was stopped. A private or Incognito window holds much less than a normal one, so receive in a normal window, or receive large files on a computer with Floe Desktop (Windows) or the Floe CLI, which save straight to disk.” These browsers keep what arrives in storage of their own, outside the tab: part of it in memory, about 2 GB on a computer, and the rest on disk. A private or Incognito window puts nothing on disk, so everything received in private windows shares the memory part alone. A normal window goes on until a limit the browser sets from the size of the disk, or until the disk is nearly full. Floe stopped when the browser had no room for the next part, and let go of the file that was arriving. Files that had already finished stay in the list. See Known limitations. Save the files that finished, close this tab, then open the same link in a normal window on the same network. A sender’s Floe page that is still open starts again by itself and sends every file from the start. If they sent withfloe send or Floe Desktop, the transfer ended on their side:
ask them to send again. If a normal window stops the same way, free some disk space, or receive
with Floe Desktop or floe receive, which write to disk as the bytes arrive.
“Something went wrong while receiving”
On the page you receive on: “Something went wrong while receiving, so the transfer was stopped. Ask the sender to try again.” Floe hit an error it did not expect while handling what arrived, and stopped rather than carry on with a file it could not vouch for. Files that had already finished stay in the list. Save the files that finished, then ask the sender to start a new transfer. If it happens again with the same files, report it: see Still stuck.“Something went wrong while sending”
On the page you send from: “Something went wrong while sending, so the transfer was stopped. Reload the page, add the files again, and share the new link.” Floe hit an error it did not expect while sending, and stopped. Files the other device had already received in full stay with it. The file that was moving did not arrive. Reload the page, add the files again, and share the new link. If it happens again with the same files, report it: see Still stuck.A banner that starts with “receiver”
On the page you send from. The receiving app stopped the transfer on purpose and said why, and the page shows its words as they arrived. With no reason given, the banner reads “The other side rejected the transfer.” These are the ones you are likely to meet:
A banner that starts “receiver” and is not listed here means the same thing: the receiving app
stopped on purpose. Start a new transfer once the cause it names is dealt with. Nothing resumes.
“The sender sent a control message larger than 1000 bytes” and similar
On the page you receive on. The sending app sent something your page refuses, so the transfer stopped. Files that arrived before it stay in the list.
The last two mean the sending app is out of date, faulty, or modified.
“The receiver asked to resume”
On the page you send from, as a red banner with the file’s name and two numbers in it:Banner
floe send stops the same way, after error sending and the file’s name, with
receiver asked to resume at byte 4096 of a 2048-byte file. The fix is the same.
“Connection failed. Reload the page to try again” or “Ask the other device to open the link again”
The connection failed in a way Floe has no closer wording for. On the page you receive on it shows before any file has finished arriving, and reads “Connection failed. Reload the page to try again. If it fails again, ask the sender for a new link.” On the page you send from it shows before any file has started moving, and reads “Connection failed. Ask the other device to open the link again. If it fails again, reload the page, add the files again, and share the new link.” On the page you send from, the status line under the share link reads “Connection failed” with this banner. It reads the same with “Connection failed. This link was made with Network relay fallback off.” and with “Connection lost. The other device may have closed the tab.”. The banner is the part that says what to do. Do what the sentence says. If it repeats on a new link, report it: see Still stuck.“Could not prepare files for ZIP.” or “ZIP creation failed.”
On the page you receive on, after you click Download ZIP. Both end withTry "Download All" instead.
- “ZIP creation failed.” means the archive would be 4 GB or more, or would hold more than 65,534 files. A ZIP that size needs an extension Floe’s archives do not use, so the page refuses it before it reads any file. It also appears when the browser runs out of room for the archive while writing it. The archive is a second copy of the files, so that happens sooner in a private window and on a phone.
- “Could not prepare files for ZIP.” means none of the files could be read back.
- A third wording, such as “1 file(s) could not be included in ZIP.”, means the archive was saved but that many files are missing from it.
Downloads behave oddly on iOS
On an iPhone or iPad, saving several files one at a time behaves inconsistently in Safari and in iOS web views. The two bulk buttons appear only for multi-file transfers, and they come and go: they show once the second file has arrived, hide while the next file is arriving, and settle when the transfer finishes. A single file is saved from the download button on its own row. Use Download ZIP when there is more than one file. If zipping fails on a very large transfer, save the files from their own rows instead.The page reloaded by itself
On either page, with no message. Floe’s web app was updated while your tab was open, and the tab asked for a part of the old version that no longer exists. It reloads once to fetch the new version, and not again within 10 seconds. For as long as your browser would ask before you leave the page, the tab is not reloaded at all. On the page you send from, that is from Create secure link until the send ends. On the page you receive on, it is while a receive is under way or a file that arrived is unsaved. On a request link’s page, it is while the page connects, waits for an answer or sends. The tab keeps the version it loaded, which carries the transfer to its end, and reloads the next time it asks for a part of the old version after that. A reload clears files you had added but not sent, and a link the page had made stops working. If you were about to send, add the files again and share the new link.“Page not found”
A page that reads “404”, “Page not found” and “That link points at nothing here. If you were sent a Floe link, check that you copied the whole thing.” It has a Send a file button and a link to How Floe works. The address matches no page on the site, which usually means a link was cut short when it was copied. Copy the whole link again. If a chat or mail app cut it, ask the sender to send it again.“Something went wrong” with a Reload page button
The whole page is replaced by “Something went wrong” and “Reload the page to try again.”, with a Reload page button. The web app itself failed. A transfer that was running in that tab has ended. Click Reload page, then start the transfer again if one was running. If it keeps happening, see Still stuck.On the command line
Most failures print one line that startsError: , and floe exits with status 1, the number a
script reads to tell that the command failed. Some lines carry
a wrapper in front of the part the headings below quote, such as WebRTC setup failed: or
error sending notes.txt: . A whole line then reads like this:
Output
Error: They stopped the transfer. A
few endings look different. A line that
starts Warning: belongs to a run that carries on. A refused link prints one sentence on a
two-space indent, with no prefix. Ctrl+C prints Canceled. and exits with status 130. See
In scripts and CI for every exit code.
code not recognized: a code is words joined by hyphens, like olive-tiger-castle
From floe receive, after could not resolve "olive_tiger_castle": with what you typed in the
quotes. What you typed is where a code goes but is not shaped like one, for example words joined
by underscores. Nothing was sent to the server.
Type the code as the sender shows it, words joined by hyphens, or paste the whole link. A code
typed with spaces between the words reaches floe as three words: see
accepts 1 arg(s).
Floe Desktop’s similar “That code wasn’t recognized” usually means something else: the server does
not know the code. See That code wasn’t recognized.
code "olive-tiger-castle" not found: it was already used, the sender left, or it expired (a code lasts 10 minutes at most)
From floe receive, after could not resolve "olive-tiger-castle": . The server does not know the
code. A code stops working when:
- someone has joined the transfer with it
- the sender left, or registered a new code
- 10 minutes have passed
- or it was mistyped.
floe 1.11.0 and earlier word it
code "olive-tiger-castle" not found or expired (codes expire after 10 minutes). See
How a transfer works.
Looking a code up does not use it up, so a receive that failed before it joined can retry the same
code. Capitalization does not matter either: floe receive and Floe Desktop lowercase what you
type, so Olive-Tiger-Castle works. Surrounding spaces and one pair of quotes or angle brackets are
removed, but a typo inside a word is not corrected.
Ask the sender for the link from the same transfer, which still works while they are waiting for
a receiver, or for a new code from a new transfer.
server returned 429 when resolving code
From floe receive, after could not resolve and the code. The server is refusing code lookups
from your network address for the moment. Wrong codes use up a small per-minute budget, and once
it is spent even a correct code is refused until the minute has passed. Floe Desktop shows
“The server is limiting requests from this network. Wait a minute and try again”
for the same refusal.
Wait a minute, check the code with the sender, and try again. Another number in the line, such as
500, means the server itself failed: try again later, or check the server if you run it.
This link looks incomplete
From floe receive and floe send --to, on a two-space indent with no Error: :
Output
floe cannot use, such
as a room id on its own. floe stops before it contacts any server, and never prints the link
back. Floe Desktop says “That link is incomplete”.
In floe 1.12 and later the same goes for a link’s link key. That covers a link
cut in its link key or at its &, a line break in a copied link, a link key that lost its k=, and
a link key pasted on its own. floe send --to in 1.11.7 prints this line for any request link from Floe Desktop 1.1 or later,
because it cannot read the link key behind the dot, and the whole link does not help there. Run
floe update.
Copy the whole link again and put it in quotes, as the line says. See
Put the link in quotes.
invalid URL or URL does not contain a room id (#room= or ?room=)
From floe receive, after could not resolve and what you pasted. invalid URL means it starts
like a link but cannot be read as one. URL does not contain a room id means the address is a Floe
page with no room in it, such as the home page, or a link a shell cut short. A share link with a
link key holds an &, and a shell ends the command there.
floe 1.11.7 and earlier print such a cut link back, link key included, as
Error: could not resolve "https://floe.one/#k=<link key>": URL does not contain a room id (#room= or ?room=).
That stays on your own screen and in your scrollback. floe 1.12 and later print
This link looks incomplete instead.
Paste the whole link from the sender, in quotes, or type the code. A code carries no link key, so a
receive by code has no check.
Couldn't confirm who sent this link. Nothing was saved. Ask them for a new link.
From floe receive 1.12 and later, on a two-space indent with no Error: . The link holds a
link key, and the sender did not prove it holds the same one, or it stopped
because it could not confirm this side. You got no prompt, and nothing was saved.
The line does not say who is at fault. A link damaged on its way to you reads the same as a server
stepping in between. Ask the sender for a new link, over another channel if you can, and tell them
what you saw. A sender may not wait for the proof, so their floe send can still have printed its
Sent box. See
What the link key checks.
Couldn't confirm the person who opened your link. Nothing was sent. Make a new link and try again.
From floe send 1.12 and later, on a two-space indent with no Error: . The other side’s proof of
the link key was wrong, or it holds the link key and refused your proof, before
it answered a file. No file’s bytes went. The first file’s name and size can have gone, because a
plain floe send does not wait for the proof before it names a file.
Run floe send again and share the new link, over a channel you trust. To name no file before the
proof, add --link-only.
Couldn't confirm the receiver. They may need to run floe update, or open the link in a browser.
From floe send --link-only, on a two-space indent with no Error: , after about 15 seconds. The
receiver showed no proof of the link key, so no file was named. Nothing else
says why. The usual cause is a receiver that cannot give a proof:
floe receivebefore 1.12, or Receive in Floe Desktop before 1.1. It prints its own update line.- A browser on a web app image older than 1.12.0. There the browser is what is old, so opening the link in a browser does not help: see What an older web app shows.
- A link that lost its link key on the way.
this connection's certificates could not be read to check the link's key
From floe 1.12 and later after Error: , and from Floe Desktop 1.1 and later after
Error: transfer failed: . This side could not read its own connection’s certificates, so it has no
proof to give and stops. It says nothing about the other side, and it should be rare.
Start the transfer again. If it repeats, report it.
invalid response from code API
From floe receive, after could not resolve and the code. floe send prints it too, after
Warning: could not generate short code: , and carries on with the link alone. Something answered
at the server address, but not with a room: for example a reverse proxy that answers /api/ with a
page of its own and status 200.
With floe receive, paste the sender’s link instead: a link needs no code lookup. Check --server
and FLOE_SERVER for a typo. On your own server, make the reverse proxy forward /api/ to the
signaling server.
this code or link is no longer active; ask the sender for a new one
From floe receive, and from Floe Desktop with the same words after Error: . floe 1.11.0 and
earlier, and Floe Desktop 0.3.0, word it this code is no longer active; ask for a new one.
The room you joined was empty, so nobody is sharing on it: the sender finished, quit, or dropped.
In practice this comes from a pasted link. A link never runs out by time, but it works only while
its sender keeps that transfer open. A room code rarely ends here, because a code stops working the
moment its room empties, and then reads
not found.
Ask the sender to start a new transfer and send you the new code or link.
room is full (someone else may already be receiving)
From floe receive, and from Floe Desktop with the same words after Error: . Someone else has
already joined this transfer: the link’s room holds a sender and a receiver. It also appears when
you join from a third network after the two of them started connecting, which the room
refuses.
A room code does not end here. A code is retired the moment a receiver joins, so a second person
who types it gets not found.
Ask the sender to start a new transfer. A second recipient needs a transfer of their own.
That link is for another Floe server
From floe receive, on a two-space indent with no Error: , before it contacts any server. A room
link names the server that holds its transfer, and that has to be the server floe is set to use.
The line says which way the two differ. A link from a self-hosted server, while floe uses
floe.one:
Output
--server or FLOE_SERVER names another server:
Output
unknown command or accepts 1 arg(s)
From floe, before it does anything. The command is missing a word, or has one too many:
cannot create output directory
From floe receive -o, followed by the folder and the reason, before it joins the transfer. The
folder you named cannot be made or written, for example one on a drive that does not exist, or one
you have no permission to write to.
Fix the path and run the command again. Nothing was joined, so the same code still works.
failed to connect to signaling server
From floe send or floe receive, followed by the address it tried and the reason. floe could
not open its realtime connection to the server: the address is wrong, the server is down, or
something in between refused it. With a code, floe receive usually stops one step earlier, at the
code lookup, with could not resolve "olive-tiger-castle": could not reach signaling server: and
the reason.
Check --server and FLOE_SERVER, then your network.
If you run the server, a reason of websocket: bad handshake means a server answered but would not
upgrade the connection, and the status in brackets says why. websocket: bad handshake (HTTP 403)
is the server’s origin check, usually a reverse proxy that rewrites the
Host header. (HTTP 404) means the proxy does not forward /ws, or forwards it under another
path. floe adds one sentence with the fix for each. See
Run behind one domain.
the server is limiting connections from this network
From floe send or floe receive, right after it starts. The whole line is
Error: the server is limiting connections from this network. Wait a minute and try again. The
server turned the connection away by one of its limits on one network address: by default 30 new
connections in a minute, and 60 open at once. Many runs in a row, many transfers at once, or many
people behind one address can reach them. floe send --to prints the same sentence with a capital
letter. Versions of floe before 1.11.2 printed
connection closed before the server assigned a role,
or failed to join room: websocket: close sent, for the same refusal.
Wait a minute, then run the command again. If it keeps happening on your own server, see
429, or “Rate limit exceeded”.
connection closed before the server assigned a role
From floe send or floe receive, right after it starts. The server accepted the connection and
then closed it before letting floe into the transfer, for a reason other than its connection
limits, which end with
the server is limiting connections from this network
instead. A server that restarted, or a proxy in front of it that closed the connection, can cause
it. A server that goes quiet instead ends with
timed out waiting for the server to assign a role after 20 seconds.
Run the command again. If it repeats, check the server, or ask whoever runs it.
Warning: could not reach signaling server for TURN credentials. Using STUN only.
From floe send or floe receive, as a warning before the transfer carries on. floe could not
get the server’s relay details, so it tries a direct connection only, through public
STUN servers. On a network that blocks direct paths the transfer will then fail.
Three warnings end Using STUN only.:
Warning: could not generate short code
From floe send, followed by the cause, for example
server returned 503 when registering code. The server did not hand out a room code, so the box
shows the link alone and the send carries on.
Share the link instead. If it happens every time on your own server, check that the reverse proxy
forwards /api/.
--relay-only needs a TURN relay
From floe send or floe receive, before the transfer starts. --relay-only sends everything
through the TURN relay and never tries a direct path, so a server that offers no
relay leaves it nowhere to go. The full line names the server it asked:
Output
FLOE_RELAY_ONLY if you set it, or add a relay to the server: see
TURN relay.
A second wording means the server was never heard from, or answered with an error, so floe cannot
say what it offers:
Output
--server for a typo, and check that a reverse proxy forwards /api/. Or wait a minute,
because that endpoint limits repeated requests from one address.
timed out waiting for the peer's offer
From floe receive, after WebRTC setup failed: . floe send prints its mirror image,
timed out waiting for the peer to answer. The other side was in the room, but for 30 seconds it
sent nothing to start the connection. Its browser tab may be asleep in the background, or the
device may have gone offline before the server noticed.
Ask the other person to bring Floe to the front, then try again. With floe receive, use the
link this time: a room code stops working once you have joined with it, so the same code now
answers not found. If the link fails as well, ask the sender to start a new transfer.
With floe send, run it again and share the new code or link.
timed out establishing a connection
From floe send or floe receive, after WebRTC setup failed: . Both sides were present and
exchanged connection details, and then 30 seconds passed without a network path that works. A peer
that never joined cannot produce this line.
The usual cause is a strict network on one side with no relay to fall back on. The relay is
missing when:
- someone passed
--no-relay, which takes the relay out of the list before connecting - a sender in the browser unchecked Network relay fallback
- the server has no relay.
connection failed (state: failed), which can print first for the same 30-second wait, and
connected but the data channel did not open. --relay-only against a server with no relay does
not end here. It stops at once with --relay-only needs a TURN relay.
Drop --no-relay if you passed it, ask the other side to allow the relay too, and run the
transfer again.
the other side left before the connection was established
From floe send or floe receive, while connecting. The server reported that the other side left
the room before the two devices finished connecting: they pressed Ctrl+C, closed or reloaded
their tab, or lost their own connection to the server. floe stops at once instead of waiting out
a timeout. floe send prints it too when a receiver joins and leaves again while the send is still
waiting.
Run the command again once the other person is ready. With floe receive, use the link or ask for
a new code: the code stopped working once both sides were in the room. With floe send, share the
new code and link it prints.
the connection to the server was lost before the peer connected
From floe send or floe receive, while connecting, or from floe send while it is still waiting
for a receiver. This computer’s own connection to the signaling server closed, so the details the
two devices still had to exchange had no way across. floe 1.11.0 and earlier printed
peer disconnected before connecting when that happened during the wait.
Check your network, then run the command again. With floe receive, use the link or ask for a new
code. With floe send, share the new code and link it prints. On a self-hosted server, check that
the server is still running.
WebRTC setup failed: and another reason
From floe send or floe receive, while connecting, for a reason the entries above do not cover.
Each line names the step that failed:
Floe Desktop can show
failed to create peer connection: as well, after Error: . The same fix
applies.
Slow to connect when a VPN or virtual machine is running
Infloe send or floe receive: a long wait while connecting, with no error. A VPN such as
Tailscale, or virtualization software such as VMware, VirtualBox, WSL, or Hyper-V, adds extra
network connections, and floe tries each one. The transfer completes in the end.
Find the name of the connection you mean: ipconfig on Windows, ip link on Linux, or ifconfig
on macOS. Then pin floe to it. The name matches any part of an interface’s name, in any letter
case:
Terminal
floe stops before it
pairs, with Error: --iface matches no network interface on this computer; check the name, or drop the flag.
An adapter that exists but is down passes that check, and the connection then fails outright.
floe 1.11.7 and earlier accept any name, and the connection fails after pairing.
floe already ignores link-local addresses, which covers dead auto-configured adapters. A VPN
adapter with a routable address, such as Tailscale’s 100.x range, is still tried.
connected, but no data arrived from the sender within 30s
From floe receive, after Connected. The connection opened, and then the sender announced no
file for 30 seconds. Their app stalled or was stopped right after connecting.
Ask the sender to start a new transfer.
timed out waiting for ack
From floe send, after error sending and the file’s name. The ack is the receiving app’s reply
that it is ready for the file, and none came within 2 minutes. On floe receive that is how long
the person has to answer Accept? [Y/n]. A connection that died without closing looks the same.
Ask the recipient to be ready at the prompt, or to pass -y, then send again.
the sender left before the transfer was accepted
From floe receive, as Error: the sender left before the transfer was accepted, when you answer
Accept? [Y/n] after the sender has gone. Their side waits 120 seconds for your answer and then
gives up, and a floe send there ends with timed out waiting for ack.
Or they stopped while you decided. Nothing was created. floe 1.11.0 and earlier started the
transfer anyway and ended with connection closed mid-transfer.
Ask the sender to send again, then answer the prompt within 2 minutes, or pass -y.
They declined. Nothing was sent.
From floe send, as Error: They declined. Nothing was sent. The recipient answered n at the
Accept? [Y/n] prompt of floe receive, and their own terminal shows transfer declined. Nothing
was sent.
Check with the recipient before you send again.
connection closed while waiting for the receiver (transfer declined or receiver exited)
From floe send. The other side’s app ended before it took the file, without saying why: for
example, floe receive was killed at its prompt. A no at the prompt of floe receive 1.11.0 or
earlier also ends this way, because that version does not tell the sender.
Check with the recipient before you send again.
relay connections are capped at 2 GB
From floe send, before any file moves, in full
transfer blocked: relay connections are capped at 2 GB (selected 2.5 GB). The connection came up
relayed and the files total more than 2 GB. With --relay-only every transfer is relayed, so the
cap always applies.
The receiver is shown the same sentence. floe receive prints whatever the sender’s app says, so
from a sender in the browser it reads
Transfer blocked: relay connections are capped at 2 GB. Ask the sender to send 2 GB or less, or to try a network that allows a direct connection.
Only the sender can change this.
Send 2 GB or less at a time, or get a direct connection, which starts with dropping
--relay-only if you passed it. See File size limits.
Error: They stopped the transfer.
From floe send. The recipient pressed Ctrl+C in floe receive 1.11.0 or later after the two
sides had connected, at its Accept? [Y/n] prompt or partway through the files. Files they had
already saved stay saved, and the file that was arriving is discarded.
Ask whether they meant to stop, then send again whatever did not arrive. Nothing resumes.
The sender stopped.
From floe receive, as Error: The sender stopped. The sender pressed Ctrl+C in floe send.
Files that finished are kept, and the file that was arriving is deleted.
A sender that stops for another reason says so, and floe receive prints its words. Examples are
the sender's copy of "report.pdf" changed while it was being sent, so nothing further was sent,
The sender stopped: a file could not be read on their device. Ask them to check it and send again.
when a file was moved, deleted, or on a drive that was unplugged, and the relay cap in
relay connections are capped at 2 GB. A floe send 1.11.7
or earlier, or a Floe Desktop 1.0.4 or earlier, whose file cannot be read gives no reason, so
floe receive prints one of the lines under
connection closed before any file arrived.
Ask whether they meant to stop, then ask them to send again whatever did not arrive.
connection closed before any file arrived (the sender canceled, or the transfer was blocked)
From floe receive. The sender’s side closed the connection without saying why: they closed their
tab, canceled or quit in Floe Desktop, or their floe send stopped with an error. A Ctrl+C in
floe send whose reason could not get out before the connection closed ends this way too. The
line depends on how far the transfer had got:
Ask the sender to send again whatever did not arrive.
transfer stalled: no data for 1m0s
From floe receive, followed by how far it got. A minute passed with no data in the middle of a
transfer: the connection is still open in name, but nothing is moving, typically because a network
dropped on one side. Files that finished are kept.
Check both networks, then ask the sender to send again whatever did not arrive.
connection closed mid-transfer, from floe send
From floe send, after error sending and the file’s name. The receiver quit, canceled, or closed
its tab in the middle of a file, or lost its network. The same event can read any of these:
connection closed mid-transfer (1048576 bytes still buffered)failed to send chunk:and a reasonfailed to send metadata:and a reason, when the connection closed just as a file was announcedbackpressure stall: peer not draining (1048576 bytes buffered)
floe receive older
than 1.11.0, it reads
connection closed before delivery was confirmed (1048576 bytes unacknowledged). The last file may
not have arrived.
Files that finished on their side are kept there, and nothing resumes. Check with the recipient
what arrived, then send the rest again.
timed out waiting for delivery confirmation from peer
From floe send, after the last file. floe sent everything, then heard nothing back for a full
minute: the receiver neither confirmed delivery nor took in more of the data still on its way. It
cannot tell whether the last part arrived. The connection has most likely stalled.
Check with the recipient what arrived before you send again.
the connection closed before the receiver confirmed delivery
From floe send, after the last file. floe send cannot tell whether everything arrived. Every
byte was sent, but the connection closed before the receiving app said it had saved every file, or
the receiver went silent for about 30 seconds. They may or may not have every file, so floe send
exits with status 1 instead of reporting success. It applies when the receiver is
floe receive 1.11.0 or later, Floe Desktop 0.3.0 or later, or a browser, where closing the tab
right after the last file arrives does it.
Check with the recipient what arrived before you send again.
the file shrank while it was being sent
From floe send, after error sending and the file’s name:
Output
the file grew while it was being sent. The file changed size on disk while floe
was reading it, as a download or an export that is still being written does. Nothing after that
file was sent, and the receiver is told why.
Wait until the file stops changing, then send it again.
cannot read or cannot send and a path
From floe send, before it contacts any server. Floe Desktop shows the same words after Error:
when you click Send. Each line names the path:
receive stopped: a file's path is too deep or too long to save in this folder
From floe receive. A file in the transfer sits too many folders deep, or its name or its path
inside the transfer is too long, for floe receive to save it safely. It refuses such a file
before writing it, and no flag turns that off. The sender sees
A file name or folder path is too long for their computer. Shorten it or zip it first.
A path long enough to make the file’s description longer than 1,000 bytes stops one step earlier,
with rejected the sender's control message: 1204 bytes, limit 1000. The fix is the same.
Ask the sender to shorten the name, or to zip deeply nested folders first. See
Paths that are too deep or too long for the limits.
rejected the sender's file description and similar lines
From floe receive. Each of these means the sending app sent something that cannot be right, so
floe stopped. Files saved before it are kept.
a file did not match the SHA-256 the sender computed, so it was not kept
From floe receive. The sender’s app works out each file’s SHA-256, a fingerprint of its
contents, and floe receive checks it. For that file the two did not match, so the file was
deleted before it took its name, and the transfer stopped. Files saved before it are kept.
A second wording, the sender's SHA-256 for a file could not be read, so the file was not kept,
means the value itself was malformed. The floe send on the other side ends with
A file changed or was damaged on the way, so their Floe deleted it.
Ask the sender to send it again. See File checks.
write error: the drive ran out of space, so the file was not kept
From floe receive. The drive you are saving to filled up while a file was arriving, so the
partial file was removed and the transfer stopped. A second wording,
write error: could not finish writing a file, so it was not kept, means the write failed for
another reason, such as a folder you cannot write to or a drive that was unplugged. Files saved
before it are kept.
Free some space, or choose another folder with -o, then ask the sender to send again.
The sender sees Their computer ran out of space. or Their computer could not save a file. The
second also appears when the receiver is a browser that ran out of memory or hit an error. Then the
fix is to receive with Floe Desktop or floe receive.
received a file in full but could not finish saving it; the complete file was kept in the save folder with a .part ending
From floe receive. The file arrived whole and passed its checks, but floe could not rename it
into place after five tries, usually because another program such as an antivirus scanner was
holding it. The transfer stopped there, and the complete file is still in the save folder under
its name plus .part, a .part file.
Remove the .part ending from that file to use it, then ask the sender for any files that were
still to come.
Cannot transfer: your floe is too old for this peer.
In any Floe app, before any file moves. It appears when the two apps speak transfer protocol
versions that do not overlap. A different release number is never the cause by itself. Every release
still accepts protocol 1, so an ordinary transfer does not produce it. One stop does, on purpose:
floe send --link-only, in floe 1.12 and later, stops a receiver that cannot prove it holds the
link, with a stop only protocol 2 can read. A floe receive from 1.10.8 to 1.11.7, or Floe Desktop
1.0.x, then prints this. A floe receive older than 1.10.8 prints
connection closed before any file arrived instead.
Each app words it its own way. Each form has a line with both sides as You: and Peer:, then
the remedy:
Update the side the message calls too old. Refresh the page to update a browser, and update Floe
Desktop through the Microsoft Store or from the download page. Update
floe with the command that
matches how you installed it:
Terminal
You: and Peer: lines are what to go by.
no files to send
From floe send, before it contacts any server. Floe Desktop shows “The folders you chose have no
files to send” when you click Send, before a code is made. Every path you gave is an empty
folder, or a folder that holds only empty folders, or only pipes, sockets or devices, which Floe
leaves out. A path that does not exist stops earlier, with
cannot read and the path.
Check the paths, and make sure there is at least one file in what you send.
floe is not found after installing
In your terminal, right after an install: the shell does not know a command named floe. Open a
new terminal and run floe version.
The install put floe in a folder that the terminal you have open does not search yet. That list
of folders is your PATH. The PowerShell script adds its install folder, under
%LOCALAPPDATA%, to your user PATH, and only a terminal opened afterward reads the change.
The macOS and Linux script installs to /usr/local/bin, or to ~/.local/bin when sudo is
missing or cannot be used. It prints a note when that folder is not on your PATH. The note gives
the line to add to the file your login shell reads: ~/.zprofile for zsh, ~/.bash_profile for
bash when you have one, ~/.profile otherwise.
If the command is still not found in a new terminal, add the install folder to your PATH. See
Install the CLI.
Cannot update a dev build.
From floe update, as Error: Cannot update a dev build., and the command exits with status 1
without changing anything. floe 1.11.0 and earlier printed the sentence alone and exited with
status 0. The binary was built from source or installed with go install, so it carries no release
version to compare and cannot replace itself.
Install a release build. The install script gives you floe update, and a
package manager updates floe with its own upgrade command. See
Install the CLI.
installed via homebrew - run `brew upgrade floe` to update
From floe update and floe update --check. A package manager owns this binary, so floe will
not replace it. The line names homebrew, scoop, or winget and that manager’s own command.
Run the command the message names.
floe tells by the binary’s path, which it matches for homebrew, cellar, caskroom,
linuxbrew, scoop, or winget. A script install in a folder with one of those words in its name
is treated the same way.
A browser recipient cannot join a CLI transfer
The web app has nowhere to type a room code: a browser joins only by opening a link. Share the link thatfloe send prints with someone in a browser, and the code with
someone on floe receive or Floe Desktop, both of which accept the link too.
In Floe Desktop
Every failure on the Send and Receive tabs is shown with anError: prefix, so a message
on screen reads Error: That code wasn't recognized. While a custom Server address is set, the
line also names that server’s host, with its port if it has one, because two people on different
servers never find each other:
Status line
“That code wasn’t recognized”
On the Receive tab. The causes are those of the CLI’snot found:
a typo, a code more than 10 minutes old, or a code already retired because a receiver joined or
the sender left. It also appears when the code belongs to a different server from the one the app
is set to, and when what you entered is neither a code nor a share link.
Check the code with the sender, or paste their link instead. If you set a Server address in
Settings, make sure the sender uses the same server.
“The server is limiting requests from this network. Wait a minute and try again”
On the Receive tab, after you enter a code. The server is refusing code lookups from your network address for the moment. Wrong codes use up a small per-minute budget, and once it is spent even a correct code is refused until the minute has passed.floe receive reports the same refusal
as server returned 429 when resolving code.
Wait a minute, check the code with the sender, and try again.
“That link is incomplete”
On the Receive tab. The link you pasted names a room id that is not complete, or, in Floe Desktop 1.1 and later, a link key that is not, usually because the end of the link was cut off when it was copied. Copy the whole link again and paste it.“Couldn’t confirm who sent this link. Nothing was received”
On the Receive tab, in Floe Desktop 1.1 and later. The link holds a link key, and the sender did not prove it holds the same one, or it stopped because it could not confirm this side. Nothing was saved. The line does not say who is at fault. A link damaged on its way to you reads the same as a server stepping in between. Ask the sender for a new link, over another channel if you can, and tell them what you saw, because their screen may say the files were sent. See What the link key checks.“Couldn’t confirm who opened your link. Nothing was sent”
On the Send tab, in Floe Desktop 1.1 and later. The other side’s proof of the link key was wrong, or it holds the link key and refused your proof, before it answered a file. No file’s bytes went. The first file’s name and size can have gone, because Send does not wait for the proof before it names a file. Past an answer, the same stop reads “They stopped the transfer”. Click Send again for a new code and link, and share the link over a channel you trust.“That link is for floe.one” or “That link is for another Floe server”
On the Receive tab, before the app contacts any server. A room link names the server that holds its transfer, and that has to be the server Floe Desktop is set to use. The line says which way the two differ:
A room code is never refused this way, because a code names no server.
“Can’t reach the server”
On the Send or Receive tab. The app could not reach the signaling server, or the server did not let it into the transfer within 20 seconds. It also appears when the app’s connection to the server dropped while a send was waiting for its receiver, or while the two devices were still connecting. Check your network. If you set a Server address in Settings, check it with Test.“The server is limiting connections from this network. Wait a minute and try again”
On the Send or Receive tab, right after you click, before any transfer exists. The server turned the connection away: by default it takes 30 new connections a minute from one network address, and holds 60 open from it at once. Floe Desktop 0.3.0 showed this as “The connection dropped before the transfer finished”. Wait a minute and try again. If it keeps happening on your own server, see 429, or “Rate limit exceeded”.“the server answered with an error this version of Floe does not know”
On the Send or Receive tab, afterError: , while Floe joins the transfer or waits for the
other person. The server turned the transfer away with an error of its own. A Floe signaling server
sends only one error at that step, for a link whose room id is not valid, and Floe Desktop has its
own line for that one. So this points at a Server address that is not a Floe signaling server.
Floe Desktop never shows the server’s own words. floe 1.12 and later print the same line for such
an error, after Error: , in place of the server’s words.
If you set a Server address in Settings, check it with Test, or clear it to go back to Floe’s
server.
“The receiver left before it started”
On the Send tab, after the code and link appeared. Someone joined with your code or link and left again before the two devices began connecting. The code and link are no longer in use. Click Send again for a new code and link, and share those.“They left before the connection was made”
On the Send or Receive tab. The other side left the room while the two devices were still connecting: they canceled, closed or reloaded their tab, or lost their own connection to the server. Floe stops at once instead of waiting out a timeout. Start again once the other person is ready. A room code is used up the moment both sides are in the room, so the old one no longer works.“Couldn’t connect the two devices”
On the Send or Receive tab. Both devices were present and exchanged connection details, and then no network path worked: 30 seconds passed, or the connection checks gave up sooner. The usual cause is a strict network on one side with no relay to fall back on. The other side refused the relay, with--no-relay on
the CLI or with Network relay fallback unchecked in the browser, or the server has no relay.
Ask the other side to allow the relay, or try from another network. If you run your own server,
click Test in Settings to see whether it offers a relay.
“Both people need Floe open at the same time”
On the Send or Receive tab. The other device was in the room but did not respond in time. Either it sent nothing to start the connection for 30 seconds, or, when you are sending tofloe receive, the person there did not answer its Accept? [Y/n] prompt within 2 minutes.
Ask the other person to bring Floe to the front and be ready, then start a new transfer.
“The sender never started sending”
On the Receive tab. Floe reached the sender, and then 30 seconds passed with no file announced. Ask the sender to start a new transfer.“The sender canceled before it started”
On the Receive tab. The sender’s side closed the connection before any file arrived: they canceled or quit in Floe Desktop, closed their tab, or their app stopped the send before it began. Ask the sender to start a new transfer.“transfer failed: The sender stopped” and the sender’s other reasons
On the Receive tab, asError: transfer failed: and the sender’s own sentence, without its
closing period. The sender stopped means they pressed Ctrl+C in floe send 1.11.1 or later. A
sender in the browser names its reason instead, and so does a floe send or Floe Desktop for a file it
can no longer read:
The sender stopped: a file could not be read on their device. Ask them to check it and send again, when a file was moved, deleted, or on a drive that was unplugged.floe send1.11.7 and earlier and Floe Desktop 1.0.4 and earlier close the connection without itThe sender stopped after waiting 2 minutes for this device to answer. Ask them to send againThe sender stopped because of an error on their side. Ask them to send againThe sender has Network relay fallback off, and this connection needs the relay. Ask them to reload, leave it on, and share a new linkthe sender stopped the transfer, in Floe Desktop 1.1 and later, for any stop from a sender that has not proved the link key. It carries none of the sender’s words
“The receiver left or declined”
On the Send tab. The connection closed while Floe was waiting for the receiver to take a file. Withfloe receive on the other side, it was killed before they answered its prompt. A no at
the prompt of floe receive 1.11.0 or earlier ends this way too. A newer floe receive tells
the sender, and this tab then shows Error: They declined. Nothing was sent.
Check with the recipient before you send again.
“They stopped the transfer”
On the Send tab. The receiving app ended the transfer on purpose and told Floe Desktop so. It is the line for someone pressingCtrl+C in floe receive 1.11.0 or later, and for a receiver
that stopped because more data arrived for a file than was announced. In Floe Desktop 1.1 and later
a decline, a missed answer or a failed link key check reads this way too once the receiver has
answered a file, because a file may have gone. Floe Desktop 0.3.0 showed
the Ctrl+C case as Error: transfer failed: They stopped this drop. In every case the files
they had already saved stay saved.
Ask the other person whether they meant to stop, then send again whatever did not arrive.
“Their computer ran out of space” and the receiver’s other reasons
On the Send tab. The receiving app stopped on purpose and named a reason, and Floe Desktop shows that reason as its own line:
Floe Desktop 0.3.0 showed each of these after
Error: transfer failed: . Files they had already
saved stay saved, and nothing resumes.
“They didn’t get a file whole, so it was discarded”
On the Send tab. The receiving app counted a different number of bytes for a file than Floe announced, threw the file away, and stopped the transfer. Files they had already saved stay saved. Send the file again. If it was still being written while it was sent, wait until it stops changing.“A file arrived incomplete and wasn’t kept”
On the Receive tab. Fewer bytes of a file arrived than the sender announced, so Floe deleted it rather than keep a file that looks whole and is not. The transfer stopped there, and files saved before it are kept. When more bytes arrived than announced, the line readsError: transfer failed: sender exceeded the announced size of and the file’s name instead.
Ask the sender to send the file again. See File checks.
“The transfer stalled”
On the Receive tab. A minute passed with no data in the middle of a transfer. Files that finished are kept, and the file that was arriving is discarded. Check both networks, then ask the sender to send again whatever did not arrive.“The connection dropped before the transfer finished”
On the Send or Receive tab. It is the app’s line for a connection that ended mid-transfer without a more specific reason:- The other side quit or lost its network.
- Nothing moved for a minute.
- When sending, every byte went out and the connection closed before the receiving app said it had saved every file.
“They discarded a file that didn’t match what was sent”
On the Send tab. The receiving app checked a file against the SHA-256 Floe sent with it, the two did not match, and it threw the file away rather than keep a damaged copy. The transfer stopped there. When Floe Desktop is the side receiving, its own line endsa file did not match the SHA-256 the sender computed, so it was not kept.
Send the file again. See File checks.
“A file changed while sending and wasn’t delivered”
On the Send or Receive tab. A file changed size on the sending computer while Floe was reading it, so Floe stopped rather than send a copy that does not match what it announced. Nothing after that file was sent. On the Send tab it was one of your files. On the Receive tab it was one of the sender’s. Wait until the file stops changing, for example until a download or an export finishes, then send it again. On the Receive tab, ask the sender to do that.“Can’t write to the save folder”
On the Receive tab. Floe could not create the folder in Save to, or a write into it failed while a file was arriving, which includes the drive running out of space. Choose another folder in Save to, or free some space, then ask the sender to send again.“A file’s path is too deep or too long to save in this folder”
On the Receive tab. A file in the transfer sits too many folders deep, or its path is too long, for Floe to save it safely, so the transfer stopped before that file was written. Ask the sender to zip deeply nested folders first. See Paths that are too deep or too long are refused.“A received file couldn’t be saved, so it was kept with a .part ending”
On the Receive tab. The file arrived whole and passed its checks, but Floe could not move it into place, usually because another program such as an antivirus scanner was holding it. The complete file is in the save folder under its name plus.part.
Remove the .part ending from that file to use it, then ask the sender for any files that were
still to come.
“Hide my IP needs a relay this server doesn’t have”
On the Send or Receive tab, and when you make a request link, while Hide my IP address is on. That setting sends every transfer through a relay, so the other person sees the relay’s address and not yours: see Hide my IP. The server answered, and its list had no relay in it. Floe stops before the transfer starts, instead of failing later as a connection that could not be made. Floe’s own server offers a relay, so this normally means a self-hosted address. Test in Settings reports the same thing about an address before you rely on it. Turn Hide my IP address off, or add a relay to your server. With it off, the other person’s device can see your IP address. See TURN relay.“Couldn’t read this server’s relay details for Hide my IP”
On the Send or Receive tab, and when you make a request link, while Hide my IP address is on. Here the server was not heard from at all, or answered with an error, so Floe cannot say whether it offers a relay. Common causes are a mistyped Server address, a reverse proxy that does not forward/api/, and the server’s limit on repeated requests from one address.
Check the Server address and run Test against it, or wait a minute and try again. Turning
Hide my IP address off lets the transfer go ahead over whatever path is available, and lets the
other person’s device see your IP address.
Every transfer is capped at 2 GB
On the Send tab, as this line:Status line
Error: transfer failed: , in the sender’s words
without their closing period:
- From
floe sendor Floe Desktop:transfer blocked: relay connections are capped at 2 GB (selected 2.5 GB) - From a sender in the browser:
Transfer blocked: relay connections are capped at 2 GB. Ask the sender to send 2 GB or less, or to try a network that allows a direct connection
The Test button says the realtime connection was refused
In Settings, after you click Test. The address is a Floe signaling server, but the WebSocket upgrade at/ws is not getting through. If you only typed an
address someone gave you, the problem is on the server’s side: send this entry to whoever runs it.
The line says what to check:
Floe Desktop 0.3.0 shows the first line for every refusal. The CLI reports the same thing as
websocket: bad handshake (HTTP 403) or (HTTP 404). See
Run behind one domain and
Production deployment.
The Test button says the API answered with an HTTP error
In Settings, after you click Test, with whatever status came back:Status line
/api/ is not reaching the server. With Hide my IP address off, nothing else in Floe Desktop
reports this failure. Connection details fall back to public STUN without a word, and the room code
fails to register, so Send shows a share link with no code. With it on, every transfer stops
with “Couldn’t read this server’s relay details for Hide my IP”
instead.
A 429 is not reported with that line. Test then says “The server is limiting requests from this
network. Wait a minute and test again”, after Error: . That is the server’s own limit on repeated
requests, and it clears in a minute.
Forward /api/ to the signaling server before you rely on the address. See
Run behind one domain.
The Test button says the server has no TURN relay
In Settings, after you click Test: “Connected, but this server has no relay: Hide my IP will not work, and some networks will not connect”. This is a pass, which is why it carries noError: prefix: the address is a working Floe signaling server. Without a relay,
Hide my IP address cannot work at all, and ordinary
transfers succeed only where the two devices can reach each other directly.
Leave Hide my IP address off on this server, or add a relay to it. See
TURN relay.
The Test button says it may be the web app rather than the signaling server
In Settings, after you click Test, with whatever status came back:Status line
http://localhost:3000 produces this.
Test never follows a redirect, so a Wi-Fi sign-in page, or a server that answers every address
with the same page, cannot pass itself off as a healthy server.
Enter the signaling server’s address, which is http://localhost:3001 in that default setup.
Server address always wants the signaling server.
The Test button says the address redirects to https://
In Settings, after you click Test:Status line
http:// address, and it answered with a redirect to https:// on the same host
name, on any port. A reverse proxy that moves plain HTTP to HTTPS does this, such as the nginx
sample in Run behind one domain with a 301, or Caddy with a 308.
Test never follows a redirect, so it stops there.
Change the start of Server address from http:// to https://, for example
https://floe.example.com, and click Test again. If your proxy serves HTTPS on another port,
put that port in the address too, for example https://floe.example.com:8443. A redirect to a
different host, such as a Wi-Fi sign-in page, still shows the
HTTP status line.
Floe Desktop 1.0.4 and earlier show the HTTP status line for this redirect too, such as
Error: That address answered HTTP 301 (likely the web app, not the server).
There is no right-click menu setting
In Settings: the Windows section, and with it Show in right-click menu, is missing. That is the Microsoft Store build. A packaged app cannot register the menu entry in a way File Explorer reads, so Floe hides the setting there. Install the build from GitHub if you need the menu entry. See Install the desktop app.The switch for the right-click menu keeps turning itself off
In Settings, under Windows: you turn Show in right-click menu on and it flips back. Windows refused the registry entry Floe tried to write, which usually means a managed or locked-down PC. Send from the Floe window instead. The menu entry is only a shortcut into it.Floe will not start
A dialog titled “Floe” that begins “Floe could not start.” When it goes on to name the Microsoft WebView2 runtime, the component that draws Floe’s window, that runtime is missing. Floe could not download it, because the PC is offline or behind a filtering proxy. Install WebView2 yourself, then start Floe again. See Install the desktop app. When the dialog names something else, or readsunknown error, copy its text and report it: see
Still stuck.
“Something went wrong” with a Reload window button
The whole window, its title bar included, is replaced by a strip with Floe’s name and three lines. They read “Something went wrong”, “Reload the window to try again” and “Closing Floe stops any transfer in progress and any open request link”. Below them are a Reload window button and a Close Floe button. Floe’s window itself failed. Transfers and request links run outside the window, so this screen does not stop one that is in progress. Click Reload window. To quit instead, click Close Floe: the strip has no close button of its own. Close Floe first stops any transfer in progress and any open request link, as the screen says. If the screen comes back, see Still stuck.Request link messages
These are the request-link messages people meet most. Each side has a complete table of its own: Request links lists every message for the person who made the link in Floe Desktop. Sending through a request link lists every message for the person sending through it.floe send --to prints several of the same
sentences in the terminal, and its messages are listed under
floe send.
A card with no button is final for that page load. Trying again then means reloading the page, and
a reload empties your file selection.
“Their computer is not connected right now”
On the sender’s page, with a Try again button.floe send --to prints “Their computer is not
connected right now. The person who made this link may have closed Floe.” Floe cannot reach the
computer that made the link: the PC is asleep or offline, or Floe there stopped without closing the
link.
A link that never existed reads the same. So does one that ended more than about a day ago, or
that had been used or had ended before the Floe server restarted. Within that day an ended link
reads “This link has ended”.
Click Try again once the other person has Floe open. Your files stay selected. From
floe send --to, run the command again. If that does not work, ask them for a new link.
If you made the link, senders get this message while your PC is asleep or offline, or while the
link’s card reads “Can’t reach the Floe server”. Keep Floe Desktop open on a PC that is awake and
online, then ask them to try again.
“This link has ended”
On the sender’s page, followed by “Ask them for a new link.”floe send --to prints “This link
has ended. Ask them for a new link.” The link was closed before anyone used it: the person who made
it clicked Close link or quit Floe, or its end time passed. On Floe Desktop 1.1 and later, the
link also ends this way after 5 senders fail its link key check: see
“A sender couldn’t be confirmed and was disconnected”. The
message stays for about a day afterward. The card has no Try again, because the link will not
come back.
Ask the person who made it for a new link.
“This link has already been used”
On the sender’s page, followed by “Ask for a new link.”floe send --to prints “This link has
already been used. Ask the person who made it for a new one.” A request link takes one drop. This
one has had it, someone else is sending through it right now, or the person who made it declined a
request and has not clicked Keep waiting.
A link also reads this way for about a day after its maker closed it while a request was waiting
for an answer. It does after a decline without Keep waiting too. Someone had connected through
it, so the server counts it as used, not as “ended”.
The server gives the same answer for a link that senders have joined more than 6 times in 1 minute.
That one clears by itself.
If you had just tried several times in a row, wait 1 minute, then reload the page or run
floe send --to again. Otherwise ask the person who made it for a new link.
“Request links are turned off right now”
On the sender’s page, and fromfloe send --to. The Floe server the link belongs to has request
links turned off, so no request link works there until they are turned back on. The server gives
this answer before it looks at the link. A link that was waiting for a sender when request links
were turned off has ended.
Click Try again later: your files stay selected. From floe send --to, run the command again
later. If it then reads “This link has ended”, ask for a new link.
“Request links are not available on this Floe server.”
On the sender’s page, and fromfloe send --to. The server did not answer the request to join
within 10 seconds. That is what a server older than 1.11.0 does: it does not know request links and
ignores the message.
On the page, click Try again once: your files stay selected. From floe send --to, check that
--server or FLOE_SERVER names the server the link was made on. If the same card comes back, or
the server is right, ask the person who made the link which server their Floe uses. If it is your
own server, update it and see Turn on request links.
“They did not answer in time. Nothing was sent.”
On the sender’s page, with a Back to files button. The person who made the link did not click Accept or Decline within their window, which is 9 minutes 45 seconds. Nothing was saved on their computer, and a missed request does not close the link. Ask them to be at their PC, then go back to your files and send again.“Couldn’t confirm their computer”
On the sender’s page, followed by “Nothing was sent. Ask the person who made this link for a new one.”floe send --to 1.12 and later prints Couldn't confirm their computer. Nothing was sent. The
link holds a link key, and the computer that answered did not prove it holds the
same one: its proof was wrong, or none came within 15 seconds. No file was named.
The line accuses nobody. A link changed on its way to you reads the same as a server stepping in
between. Ask the person who made the link for a new one, over another channel if you can. See
What the link key checks.
“Their computer couldn’t confirm this link”
On the sender’s page and fromfloe send --to 1.12 and later, then how many files were saved, then
“Ask the person who made this link for a new one.” Their Floe holds a link key
and refused the proof it got from your side, usually because your copy of the link was changed on the
way. A link cut before its link key reads “This link looks incomplete” instead: see
Send files through a request link.
Do what the line says.
“A sender couldn’t be confirmed and was disconnected”
In Floe Desktop 1.1 and later, on a link that is waiting again. Someone connected to your link and did not prove they hold its link key. You got no request, no notification and no flash, nothing was saved, and the link still works. The cause can be a sender whose copy of the link was changed or cut, or a server stepping in between. The fifth such sender on one link closes it, with “Link closed after 5 senders couldn’t be confirmed”, and the next sender reads “This link has ended”. If you expected someone, send them the whole link again, and if the link closed, click Make another link. See A sender that fails the check.“Request links are off on this server”
In Floe Desktop, when you make a link, while one is waiting, or when you click Keep waiting after a decline. The server has request links turned off, so a link that was open has ended. Only request links stop: Send and Receive with a code still work. Try again later, or ask whoever runs the server. If it is your own server, see Turn on request links: its/health answer lists request-1 under
features only while request links are on. A server from before request links gets
“This Floe server doesn’t offer request links”
instead.
“This Floe server doesn’t offer request links”
In Floe Desktop, when you click Make link. The server is older than 1.11.0: its/health answer
has no features list, because it was released before request links, and no setting on it turns
them on. Send and Receive with a code still work. Earlier versions of Floe Desktop said “Request
links are off on this server” here.
Ask whoever runs the server to update it to 1.11.0 or later. If it is your own server, update it,
then see Turn on request links.
“This network reached today’s link limit”
In Floe Desktop, when you make a link. The server allows 20 new request links from one network in any 24 hours, and a link you closed still counts toward that. A network that already has 10 links open, or a server that is full, gets “Couldn’t make a link” instead. Wait, then make the link again. See Request links.“The sender couldn’t connect”
In Floe Desktop, on a link that is waiting again. Someone clicked Send on your link, but their browser orfloe and your PC could not finish connecting, or connected and then announced no file
for 30 seconds. The link is still open.
With Hide my IP address on, the line can read “The sender couldn’t connect: Hide my IP is on
and no relay is available”. The server offered no relay, or its list could not be read.
Ask them to try again. If it keeps happening, a network on one side may be blocking the
connection: see The transfer never starts.
The link opens a page that is not Floe’s send page
In the browser of the person you sent the link to, on a self-hosted server. Floe Desktop builds the link from Share link address, or from Server address when that field is blank. With the web client on its own port or hostname, a blank field points the link at the signaling server, which has no such page. Set Share link address to the web client’s address in Settings, then make a new link. See Turn on request links.On a self-hosted instance
These are for whoever runs the server. Most clear once one setting is right and the service is restarted.The browser cannot connect to my signaling server
On your own web client: the page loads, but the badge at the top of the card stays on Offline. The page is dialing the wrong address for the signaling server, or one the browser cannot reach.1
Check what the client is serving
Terminal
socketUrl means the browser uses its own origin, which is correct only when both
services sit behind one reverse proxy. Otherwise the address has
to be reachable from your users’ browsers: http://localhost:3001 works only when the browser
is on the same machine as the server.2
Set the address
The client reads it at runtime. With Compose, set
NEXT_PUBLIC_SOCKET_URL in .env: Compose
passes it into the container as SOCKET_URL, the name the running client reads. Without
Compose, set SOCKET_URL on the client process. Setting NEXT_PUBLIC_SOCKET_URL on an
already-built client does nothing, because Next inlines that name at build time.3
Recreate the container
No rebuild is needed:
Terminal
CLIENT_URL to the exact origin the page is served from, port included, as
described under
Browser requests are blocked, and the server answers HTTP 403.
Browser requests are blocked, and the server answers HTTP 403
In the browser’s console as a generic CORS failure, and in the server log asRefused a request with 403. The page’s origin, its scheme, hostname and port, is not one the
server allows. The server answers 403 with {"error":"Bad request"}, and the log line does not
name the refused origin.
Set CLIENT_URL to your client’s public origin, exactly: with the scheme, with no trailing slash,
and as one origin only, because a comma-separated list matches nothing. https://floe.one,
https://www.floe.one, and http://localhost:3000 are always allowed in addition. Then restart
the server, which reads CLIENT_URL once at startup: docker compose up -d, or a plain restart
without Docker.
Server releases v1.10.0 to v1.10.11 answer 500 with {"error":"Internal server error"} and log
a stack trace instead, and earlier ones answer 500 with an HTML error page.
The server logs Refused a connection on /ws from Origin
In the server log, at most once for /ws and once for /socket.io for as long as the server
runs. A realtime connection arrived with an Origin that is not CLIENT_URL, a floe.one origin,
or the server’s own host, and was refused. The line quotes the Origin and the Host it compared.
On the other end, floe prints websocket: bad handshake (HTTP 403), and the Test button in
Floe Desktop says the realtime connection was refused. The usual cause is a reverse proxy that
rewrites the Host header to its upstream address. The address floe and Floe Desktop send as
their origin then no longer matches it.
Pass the original Host header through the proxy, and set CLIENT_URL to the web client’s
origin. See Production deployment.
429, or “Rate limit exceeded”
From the server: an HTTP request answered429, or a realtime connection refused with the reason
Rate limit exceeded. Each limit counts one network address. All but one count over 60 seconds;
the cap on open connections counts what is open now and frees a place whenever one closes. Every
limit clears by itself, so wait a minute first. Raise a variable only when real users behind one address keep
reaching it, and restart the server afterward, because it reads the limits once at startup. What
was refused tells you which limit it was:
A refused attempt is not counted, so a client that keeps retrying is let back in as its earlier
requests pass out of the 60 seconds. At the cap on open connections, it is let in once one of them
closes. When everyone is refused at once behind a reverse proxy, the
server is usually counting every user under the proxy’s address, which
TRUSTED_PROXY_COUNT
corrects. See Configuration for each default, for how an IPv6 address
is counted, and for TRUSTED_PROXY_COUNT.
503 “Server busy, try again shortly”
FromPOST /api/code, the request that makes a room code. floe send shows it as
Warning: could not generate short code: server returned 503 when registering code and carries on
with its link alone, and Floe Desktop shows a share link with no code.
The server keeps at most MAX_ACTIVE_CODES live room codes at a time, counted across every
address, to bound the memory they use. It holds that many now. A slot frees as soon as its code is
retired, so a code that is used straight away does not hold its slot for long.
Wait, because slots free by themselves. Raise MAX_ACTIVE_CODES only if you really expect that
many transfers waiting at once. See Configuration.
The TURN relay is not working
No message of its own. Transfers that need the relay fail: the browser shows one of the “Connection failed” banners,floe prints
timed out establishing a connection, and Floe Desktop
says “Couldn’t connect the two devices”. The Test button
in Floe Desktop reports no relay. Ask the server what it hands out:
Terminal
stun:stun.cloudflare.com:3478 one with no credentials, and a turn:/turns: one that carries a
username and credential. Google STUN servers in its place mean that no Cloudflare credentials could
be made and the coturn pair is not set. One of CLOUDFLARE_TURN_KEY_ID and
CLOUDFLARE_TURN_KEY_API_TOKEN is missing or wrong, or the server could not reach Cloudflare’s API.
With TURN_SECRET and TURN_DOMAIN both set, a failed request falls back to the coturn entries
instead.
- Both variables are read once at startup. With only one of them set, the server logs a line starting
Only one of. A server image of version 1.11.7 or earlier logs nothing. - An answer is reused for 5 minutes.
- If Cloudflare stops answering, the server keeps serving the last good answer for up to about 23 hours after it was made.
- Each failure logs
Cloudflare TURN mint failedwith a reason, such asTimeoutErrororstatus 401, at most once every 5 minutes.
TURN_TLS=off). TURN_SECRET and
TURN_DOMAIN have to match coturn’s static-auth-secret and realm. With only one of the two set,
the server offers no relay and logs a line starting Only one of. A TURN_DOMAIN with a scheme, a port
or a path turns the relay off too, and logs a line starting TURN_DOMAIN holds. A server image of version 1.11.7 or earlier logs neither.
Fix the variables, then restart the server so that it reads them: docker compose up -d, or a
plain restart without Docker. See TURN relay.
coturn logs Default realm: localdomain
In coturn’s log. coturn is running on its built-in defaults with no auth secret, so relaying fails
without any error for exactly the peers it exists to serve. This happens when
coturn/turnserver.conf did not exist before the first docker compose --profile turn up, so
Docker created a directory at that path. Copying a file onto that directory succeeds and writes
the file inside it, so the obvious fix appears to work and does not.
Remove the directory first, then fetch the example config:
Terminal
static-auth-secret and realm in the file to match TURN_SECRET and TURN_DOMAIN, then
start coturn again. Keep --force-recreate: a coturn that is still running keeps the old
directory, and a plain up -d leaves a running container as it is:
Terminal
The server logs nothing at all
Indocker logs, or in the terminal after npm start: nothing. That is expected. The signaling
server has no access log and no startup banner, not even a “listening on” line, so the log of a
healthy server is usually empty. Three kinds of refusal leave a line. An HTTP request from a
browser origin the server does not allow, or one whose body it cannot read, leaves a short line
such as Refused a request with 403.. A connection from an origin the server does not accept
leaves one Refused a connection on /ws from Origin ... line per path for as long as the server
runs. A refusal from the limits on repeated requests leaves nothing.
See Operations.
A few startup lines can appear. request links: on means the policy file turned
request links on, and a line saying the policy file was not found
or is unreadable means they stayed off. A server started with Node directly and without
TRUSTED_PROXY_COUNT writes one line saying which proxy count is in use. A server given a word or
a negative number for it writes one line saying 0 is in use. A MAX_* variable that is not a
whole number of at least 1 gets one line naming it and the default now in use. Half of a pair of
variables gets a line starting Only one of, and a TURN_DOMAIN that holds more than a hostname a
line starting TURN_DOMAIN holds. Upstash settings that do not work get one Upstash counter line:
read failed at startup, or update failed at the first report. A server image of version 1.11.7 or earlier writes none of these last three.
Use GET /health, which returns {"status":"healthy","uptime":<seconds>,"features":[...]}, to
confirm the server is alive and to see whether a restart landed.
Still stuck
For a question or an idea rather than a bug, ask in GitHub Discussions. For a bug, open an issue on GitHub with these details:- The exact message you saw, and which side of the transfer showed it.
- The app on each side, and its version:
floe versionfor the CLI, and the image tag for a self-hosted server. - Your operating system, and the browser if one was involved.
- Whether the connection was direct or relayed. The terminal prints
Connected (direct)orConnected (relay), and the badge on the web card reads Direct or Relay.