`sf org open` not working under Linux (Snap)

[fmannreply]

Summary

Running sf org open under Ubuntu 22.04 with latest sf cli 2.30.8 opens Firefox with "file:////tmp/org-open-1710254619760.html" and shows "File not found".

Steps To Reproduce

• Authorize any org
• Open org

Expected result

Org opens

Actual result

Org doesn't open and browser shows "File not found".

System Information

Terminal: Bash & Powershell 7.4 (same behavior)

{
  "architecture": "linux-x64",
  "cliVersion": "@salesforce/cli/2.30.8",
  "nodeVersion": "node-v20.11.1",
  "osVersion": "Linux 6.5.0-25-generic",
  "rootPath": "/home/fmann/.nvm/versions/node/v20.11.1/lib/node_modules/@salesforce/cli",
  "shell": "bash",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.0.9 (core)",
    "@oclif/plugin-commands 3.1.4 (core)",
    "@oclif/plugin-help 6.0.13 (core)",
    "@oclif/plugin-not-found 3.0.11 (core)",
    "@oclif/plugin-plugins 4.2.5 (core)",
    "@oclif/plugin-search 1.0.16 (core)",
    "@oclif/plugin-update 4.1.13 (core)",
    "@oclif/plugin-version 2.0.12 (core)",
    "@oclif/plugin-warn-if-update-available 3.0.12 (core)",
    "@oclif/plugin-which 3.1.0 (core)",
    "@salesforce/cli 2.30.8 (core)",
    "apex 3.0.25 (core)",
    "auth 3.3.13 (core)",
    "data 3.1.1 (core)",
    "deploy-retrieve 3.2.16 (core)",
    "dev 1.1.3 (user)",
    "info 3.0.27 (core)",
    "limits 3.1.10 (core)",
    "marketplace 1.0.25 (core)",
    "org 3.3.14 (core)",
    "packaging 2.1.10 (core)",
    "schema 3.1.3 (core)",
    "settings 2.0.27 (core)",
    "sobject 1.1.13 (core)",
    "source 3.1.15 (core)",
    "telemetry 3.1.13 (core)",
    "templates 56.0.16 (core)",
    "trust 3.3.10 (core)",
    "user 3.2.11 (core)",
    "sfdx-git-delta 5.24.0 (user)",
    "sfdx-plugin-source-read 1.2.0 (user)"
  ]
}

Additional information

The last working version was @salesforce/cli@2.24.4. Maybe it has something to do with #923.
Workaround is to run sf org open --url-only and paste the url manually into the browser or pipe it to firefox.

[github-actions]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[shetzel]

It's the change in behavior from this PR: salesforcecli/plugin-org#913

My guess is that the temp file is being deleted before the browser can load it. Does this happen 100% of the time for you? Does it matter if Firefox is already open? Does another browser work more consistently?

[shetzel]

Can you try modifying this file: /home/fmann/.nvm/versions/node/v20.11.1/lib/node_modules/@salesforce/cli/node_modules/@salesforce/plugin-org/lib/commands/org/open.js
to bump the sleep time so that line 129 is:
await sleep(platform() === 'win32' || isWsl ? 7000 : 10_000);

Let me know if that allows enough time for the redirect. Thanks!

[fmannreply]

Hi @shetzel, thanks for getting back to me. I did some investigation, tldr even when removing fileCleanup(tempFilePath) and opening the file manually it doesn't open.

Turns out it's due to snap sandboxing, the global /tmp is not visible to it, only /home/tmp and /tmp/snap-private-tmp/snap.firefox/tmp/. (https://superuser.com/a/1748690). Thats why I also observed the same with chromium as it's also snap.

I will investigate a bit more on what the suggested solution is.

[iowillhoit]

For future reference, see salesforcecli/plugin-org#992 (comment) for a work around on this issue.

[cristiand391]

We'll keep this issue open until the tmpfile-based logic is removed.

some notes about the tmp env var workaround:

1. the code tries to delete the file, but even in a failure the default tmp dir is cleaned after a reboot on linux/mac (IIRC that's not the case on windows). If you are setting TMPDIR make sure the file is getting deleted (it contains a token).
2. another workaround could be running sf org open --url-only --json and extract the url with jq, then run open <url> in your terminal. --url-only returns an URL with the token in it so make sure it doesn't get logged in the terminal.