Extension displays `Your host device is not running Tailscale` erroneously [but works just fine]

[tailscale]

Extension displays `Your host device is not running Tailscale` erroneously [but works just fine]

[QuantumLibet]

At this point, I don't think we'd rename that binary because of how people rely on it.

Good point. I hate updates that break my scripts, just as much as anybody else.

An alias is a good solution. It's what they are for. Currently I just add a symbolic link from tailscale to Tailscale, which works fine as well.

[QuantumLibet]

The update from Tailscale Docker-Extension 0.0.10 to 0.0.11 did not fix the issue.

Could the problem be related to the App Store version of the Tailscale client? The App Store client does not expose the tailscale command, which adds it's very own complexity (like following instructions like this). Does the Docker-Extension rely on the executable?

[QuantumLibet]

The update from Tailscale Docker-Extension 0.0.11 to 0.0.12 did not fix the issue.

FWIW

[rosszurowski]

Hi! Sorry for the trouble, and thanks for reporting this. Our "is Tailscale installed" check is a little hacky, since it just checks a particular path. It looks like you're running macOS, which would run this code when checking.

Where is your local copy of Tailscale.app installed? Maybe there are ways we can make our check more robust.

[QuantumLibet]

Tailscale has been installed from the App Store and is in the default location of /Application/Tailscale.app.

Copying the linked file locally and executing it with /bin/sh -x ./host-tailscale present returns no error/0 (as expected).
Quitting Tailscale and executing the script with … start will start Tailscale (as expected).
Executing … status can't be tested here, since I wouldn't know how the script is called and what value $2 could/would/should have.

Since the script works fine, could it be something in the function calling the script?

[rosszurowski]

Hmm, the core block which runs that script is found here.

Reviewing the code again, it looks like it's correctly finding that you have Tailscale installed, it just can't detect that it's currently running. (Hence the "not running Tailscale" language, which could be improved). I think it may be failing in the status block — either it can't run tailscale status, or it's getting an unexpected result back.

Can you run this command, and post the output of a few fields?

/Applications/Tailscale.app/Contents/MacOS/tailscale status --json

This will return a big JSON blob. Don't post it here, since the endpoint IPs can be private information, but I'm interested in the values of these fields: Version, BackendState, and Self.UserID.

[QuantumLibet]

/Applications/Tailscale.app/Contents/MacOS/tailscale status --json

Ah! That won't work, since the executable from the AppStore sports a capital 'T' on case-sensitive APFS installations. As in /Applications/Tailscale.app/Contents/MacOS/Tailscale status --json. Had me fall on my nose a couple of times already when I used the CLI commands.

$ ll /Applications/Tailscale.app/Contents/MacOS/
total 12892
-rwxr-xr-x  1 0    31M  7 Jul 00:56 Tailscale

If macOSTailscalePath in your linked code does not expect the capital-T-tailscale-executable, then that would explain a lot.

The output anyways:

$ /Applications/Tailscale.app/Contents/MacOS/Tailscale status --json | grep -e 'Version\|BackendState\|UserID'
  "Version": "1.26.2-t9e47908f1-g9d2e332ad",
  "BackendState": "Running",
    "UserID": 19836734270013662

[rosszurowski]

Ahhh, shoot. I thought the executable was lowercase. That explains it! I'll make a fix.

Thanks again for reporting and troubleshooting with me.

[QuantumLibet]

Thank you for being so nice and helpful. 🫡

I saw #39, but I had quietly hoped you'd fix the App Store application bundle, instead of the Docker Extension. Scripts that run perfectly fine on all sorts of Unixy/Linuxy systems fail miserably on macOS bc of the weird renaming. I know how annoying the wait can be for a new App Store release, but then, it would streamline things so much...

[rosszurowski]

At this point, I don't think we'd rename that binary because of how people rely on it. We may be able to provide an alias within our bundle if that'd help. But for these scripts that run cross-platform on unix-y systems that fail on macOS, don't you already have to provide a custom path to the script anyways?

(As a side note, our official recommendation for folks using the CLI on macOS is to set up an alias for easy access)