This is Debian 9 Stretch speaking, #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21), with a new, portable installation of Firefox 62.0 run from /opt with

$ which firefox

My problem is that, even though the command

$ firefox

does launch and run a firefox instance, a subsequent command

$ firefox any.kind/of/url

fails with the famous window message

Firefox is already running, but is not responding. To open a new window, you must first close the existing Firefox process, or restart your system.

whereas it used to just open a new tab for the provided url in the existing, running session.

The options --new-tab, --new-window or --no-remote do not help. And I have checked according to this post, that


.. which I think should mean that my desired behaviour is the expected behaviour. (Note that it is not clear to me what is the init file they refer to in this post).

As (I-think-)related problems:

  • clicking a link in a .pdf file opened with evince also fails with the same error message.
  • cliking a link in an e-mail viewed in thunderbird also fails with the same error message.

Am I missing anything here?
How do I add a new tab to the running browser session from the command line?
Any way to solve / get around this problem?

  • Are you running your second copy of firefox using the same user in the same X session? – kostix Sep 19 '18 at 20:18
  • 1
    As a data point, I tested this with Ubuntu 18.04, which is based on Debian 10 Buster, and Firefox v62 installed from the Ubuntu repo (not portable). It worked as intended ("firefox URL" opens the URL in a new tab of the open Firefox). That would seem to narrow it down to the portable version of Firefox and/or Firefox's behavior in Debian 9. – fixer1234 Sep 20 '18 at 4:13
  • @kostix Yes I am. Both commands are send from two neighbouring terminal emulators. – iago-lito Sep 20 '18 at 8:07
  • @fixer1234 Cheers :) – iago-lito Sep 20 '18 at 8:07
  • Another data point: On my Debian Stretch, Firefox ESR works just fine with --new-tab: it says an already running copy to open the specified URL in a new tab. That's 60.2.0esr (amd64) from the official repo (now as a security update). – kostix Sep 20 '18 at 15:42

Okay, got it. According to this post, the actual value of MOZ_NO_REMOTE environment variable does not matter, only the fact that it is defined or not. So MOZ_NO_REMOTE=0 is suprisingly synonym of MOZ_NO_REMOTE=1.

So after I removed this line

export MOZ_NO_REMOTE=0

that somehow sneaked into my .[bash|zsh]rc files, and checked that


I got my good ol' behaviour back :)

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.