Can't use Joplin (Terminal version) in macOS

Hey,
I don’t know why, but the the joplin (terminal version) doesn’t work in my mac. When I run the command > joplin, it just throws an error about some required stack of modules.
Is someone familiar with the problem?

Thanks in advance for your help and time!

Please complain to brew as we do not manage the brew packages.

Or as I always recommend: install node 10.16.x and then use npm install -g joplin to install the terminal client.

2 Likes

Than you very much!
It worked!
with the npm package of course

You are welcome.

Brew are other packages might be easier at fiirst glance, but they might get dependencies wrong or could be outdated. Thus I usually stick to the basics.

1 Like

Hi @tessus,

I tried to install the Terminal version on an old Air notebook with Lion (macOS 10.7.5) on it. The newest freshly installed Node version (12.16.0) produced a segmentation fault (even at node -v), so I installed 10.16.0, the lowest one that would hopefully work on Lion. It did. But the installation of Joplin failed:

1586 silly fetchPackageMetaData error for node-emoji@git+https://github.com/laurent22/node-emoji.git Error while executing:
1586 silly fetchPackageMetaData /usr/bin/git ls-remote -h -t https://github.com/laurent22/node-emoji.git
1586 silly fetchPackageMetaData
1586 silly fetchPackageMetaData error: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version while accessing https://github.com/laurent22/node-emoji.git/info/refs
1586 silly fetchPackageMetaData
1586 silly fetchPackageMetaData fatal: HTTP request failed
1586 silly fetchPackageMetaData
1586 silly fetchPackageMetaData exited with error code: 128
1587 http fetch GET 200 https://registry.npmjs.org/emphasize 1104ms
1588 http fetch GET 200 https://registry.npmjs.org/emphasize/-/emphasize-1.5.0.tgz 149ms
1589 silly pacote range manifest for emphasize@^1.5.0 fetched in 1257ms
1590 silly resolveWithNewModule emphasize@1.5.0 checking installable status
1591 timing stage:rollbackFailedOptional Completed in 1ms
1592 timing stage:runTopLevelLifecycles Completed in 34054ms
1593 verbose stack Error: exited with error code: 128
1593 verbose stack     at ChildProcess.<anonymous> (/usr/local/lib/node_modules/npm/node_modules/pacote/lib/util/finished.js:12:19)
1593 verbose stack     at ChildProcess.emit (events.js:198:13)
1593 verbose stack     at maybeClose (internal/child_process.js:982:16)
1593 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:259:5)
1594 verbose cwd /Users/meimar
1595 verbose Darwin 11.4.2
1596 verbose argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" "-g" "joplin"
1597 verbose node v10.16.0
1598 verbose npm  v6.9.0
1599 error Error while executing:
1599 error /usr/bin/git ls-remote -h -t https://github.com/laurent22/node-emoji.git
1599 error
1599 error error: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version while accessing https://github.com/laurent22/node-emoji.git/info/refs
1599 error
1599 error fatal: HTTP request failed
1599 error
1599 error exited with error code: 128
1600 verbose exit [ 1, true ]

Any idea what was going on here?

It looks like git can’t negotiate a TLS handshake:

error: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version while accessing https://github.com/laurent22/node-emoji.git/info/refs

I tried to do the same thing on a more up-to-date iMac (Mojave) with Node 12.6.0. Everything went fine, until something sharp appeared on the scene:

11325 silly install sharp@0.23.4
11326 info lifecycle sharp@0.23.4~install: sharp@0.23.4
11327 verbose lifecycle sharp@0.23.4~install: unsafe-perm in lifecycle false
11328 verbose lifecycle sharp@0.23.4~install: PATH: /usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin:/usr/local/lib/node_modules/joplin/node_modules/sharp/node_modules/.bin:/usr/local/lib/node_modules/joplin/node_modules/.bin:/usr/local/lib/node_modules/.bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/share/dotnet:/opt/X11/bin:~/.dotnet/tools:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/Applications/Xamarin Workbooks.app/Contents/SharedSupport/path-bin
11329 verbose lifecycle sharp@0.23.4~install: CWD: /usr/local/lib/node_modules/joplin/node_modules/sharp
11330 silly lifecycle sharp@0.23.4~install: Args: [
11330 silly lifecycle   '-c',
11330 silly lifecycle   '(node install/libvips && node install/dll-copy && prebuild-install) || (node-gyp rebuild && node install/dll-copy)'
11330 silly lifecycle ]
11331 silly lifecycle sharp@0.23.4~install: Returned: code: 1  signal: null
11332 info lifecycle sharp@0.23.4~install: Failed to exec install script
11333 timing action:install Completed in 5308ms
11334 verbose unlock done using /Users/meindert/.npm/_locks/staging-3a08f0df5026584d.lock for /usr/local/lib/node_modules/.staging
11335 timing stage:rollbackFailedOptional Completed in 1040ms
11336 timing stage:runTopLevelLifecycles Completed in 43492ms
11337 verbose stack Error: sharp@0.23.4 install: `(node install/libvips && node install/dll-copy && prebuild-install) || (node-gyp rebuild && node install/dll-copy)`
11337 verbose stack Exit status 1
11337 verbose stack     at EventEmitter.<anonymous> (/usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/index.js:332:16)
11337 verbose stack     at EventEmitter.emit (events.js:321:20)
11337 verbose stack     at ChildProcess.<anonymous> (/usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/lib/spawn.js:55:14)
11337 verbose stack     at ChildProcess.emit (events.js:321:20)
11337 verbose stack     at maybeClose (internal/child_process.js:1021:16)
11337 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:286:5)
11338 verbose pkgid sharp@0.23.4
11339 verbose cwd /Users/meindert
11340 verbose Darwin 18.7.0
11341 verbose argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" "-g" "joplin"
11342 verbose node v12.16.0
11343 verbose npm  v6.13.4
11344 error code ELIFECYCLE
11345 error errno 1
11346 error sharp@0.23.4 install: `(node install/libvips && node install/dll-copy && prebuild-install) || (node-gyp rebuild && node install/dll-copy)`
11346 error Exit status 1
11347 error Failed at the sharp@0.23.4 install script.
11347 error This is probably not a problem with npm. There is likely additional logging output above.
11348 verbose exit [ 1, true ]

So the whole thing was rolled back, and I stood empty-handed again.

(Needles to say that homebrew does not work. I didn’t even get it installed on the Air, due to a syntax error in the Ruby code. I succeeded to install on the iMac, but giving it a chance with Joplin ended as in the OP. Why is homebrew still mentioned on the homepage of the Joplin site?)

I’ve never seen this error before. I’m also using macOS 10.14.x.

Did you run this as a user or root? If you run it as a user you’ll have to change the npm global path, otherwise it will fail due to permission errors.

I started under an administrator account with npm install -g joplin and got a permission issue indeed:

1676 warn checkPermissions Missing write access to /usr/local/lib/node_modules
1677 timing stage:rollbackFailedOptional Completed in 1ms
1678 timing stage:runTopLevelLifecycles Completed in 42038ms
1679 verbose stack Error: EACCES: permission denied, access '/usr/local/lib/node_modules'
1680 verbose cwd /Users/meindert
1681 verbose Darwin 18.7.0
1682 verbose argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" "-g" "joplin"
1683 verbose node v12.16.0
1684 verbose npm  v6.13.4
1685 error code EACCES
1686 error syscall access
1687 error path /usr/local/lib/node_modules
1688 error errno -13
1689 error Error: EACCES: permission denied, access '/usr/local/lib/node_modules'
1689 error  [Error: EACCES: permission denied, access '/usr/local/lib/node_modules'] {
1689 error   stack: "Error: EACCES: permission denied, access '/usr/local/lib/node_modules'",
1689 error   errno: -13,
1689 error   code: 'EACCES',
1689 error   syscall: 'access',
1689 error   path: '/usr/local/lib/node_modules'
1689 error }
1690 error The operation was rejected by your operating system.
1690 error It is likely you do not have the permissions to access this file as the current user
1690 error
1690 error If you believe this might be a permissions issue, please double-check the
1690 error permissions of the file and its containing directories, or try running
1690 error the command again as root/Administrator.
1691 verbose exit [ -13, true ]

Then I resumed with sudo npm install -g joplin, and the installation was picked up again:

2001 silly decomposeActions install crypt@0.0.2
2002 silly decomposeActions postinstall crypt@0.0.2
2003 silly decomposeActions finalize crypt@0.0.2 
...
11347 error Failed at the sharp@0.23.4 install script.
11347 error This is probably not a problem with npm. There is likely additional logging output above.
11348 verbose exit [ 1, true ] 

That additional logging is problably the part from 11325 (see my previous post). No idea if the numbering gap between 1691 and 2001 indicates that something vital has been skipped.

I can’t replicate this error.

You don’t have to, since it looks like the problem is solved now. I just restarted Mojave and tried sudo npm install -g joplin again. Same error. It’s not in the log, but on the console this suggestion was given:

info sharp Are you trying to install as a root or sudo user? Try again with the --unsafe-perm flag 

And behold, sudo npm install --unsafe-perm -g joplin did the job! Conclusion: just sudo and being administrator doesn’t make you immediately omnipotent.

How about Lion? I’ve found out that Node 11.15.0 is the most recent version that can run on it. And it produces the same negotiation error as before. Does 11.15.0 use the wrong hand, or is the culprit hiding itself somewhere in the basement of macOS? I’m afraid we can’t do anything about it other than upgrade macOS to a version that still fits on the old apparatus, which would regrettably break other things on it. So I think I have to give this one up.

Strange that you couldn’t reproduce my Mojave behavior, isn’t it? Informative all the same. Evidently Mojave != Mojave. I’m grateful for your involvement.

I never had to use --unsafe-perm. But as I mentioned before I set a different global npm dir for my user. So I did not use sudo either. I wrote a short note a while back how to setup node and npm manually. Maybe it helps:

Install nodejs manually

  1. Unzip the binary distribution to /usr/local/lib/nodejs/node-vX.Y.Z
  2. add the following to .bash_profile
    export NODEJS_HOME=/usr/local/lib/nodejs/node-vX.Y.Z/bin
    PATH=$HOME/bin:$NODEJS_HOME:$PATH
    

Download: https://nodejs.org/en/download/

Changing the location of global packages (npm)

  1. Set a new prefix path
    $ npm config get prefix
    $ cd ~ && mkdir .node_modules_global
    $ npm config set prefix=$HOME/.node_modules_global
    
    $ cd ~ && mkdir .npm-global
    $ npm config set prefix=$HOME/.npm-global
    
  2. add to .bash_profile
    export NODEJS_GLOBAL_HOME=$HOME/.node_modules_global/bin
    export NODEJS_GLOBAL_HOME=$HOME/.npm-global/bin
    
    PATH=$HOME/bin:$NODEJS_GLOBAL_HOME:$NODEJS_HOME:$PATH
    
  3. Install latest version of npm
    $ npm install -g npm
    

That looks like locking Node up in one specific folder /usr/local/lib/nodejs/node-vX.Y.Z instead of spreading it over /usr/local. At first glance I don’t see what difference it would make from the authorization point of view (all subfolders are 775 on my iMac), but I’ll keep your recommendations in my mind Joplin.

The most surprising is that the obstacle was ~/.npm/_libvips (755). The owner was root, where most of its siblings, created at the same time, were owned by my account meindert. I cannot blame sudo for that, can I?

Interesting stuff anyway. I’ll document these findings in Joplin, of course!

Edit:
I see now that lower levels of usr/local/<something> are also owned by root. It’s a bit of a mess,really. Maybe I should do the whole operation Node + Joplin again, according to your scheme.

I’m not sure how to interpret the Changing the location… part. As an exclusive choice between (1) and (2)?

$ npm config get prefix
$ cd ~ && mkdir .node_modules_global                        | (1)
$ npm config set prefix=$HOME/.node_modules_global          |

$ cd ~ && mkdir .npm-global                                 | (2)
$ npm config set prefix=$HOME/.npm-global                   |
export NODEJS_GLOBAL_HOME=$HOME/.node_modules_global/bin    | (1)
export NODEJS_GLOBAL_HOME=$HOME/.npm-global/bin             | (2)

PATH=$HOME/bin:$NODEJS_GLOBAL_HOME:$NODEJS_HOME:$PATH

Yes, sorry about that. Those were my personal notes. On one of my machines I used the first one, but then thought that the path was too long. Thus I used a shorter one for the other machine.

I kept both dirs for my record.

Maybe I should have used parameter markers in my notes…

Okay, I’ve pulled out all roots, replanted Node in the elegant way described above, and now it’s flourishing again and capable of installing Joplin Terminal without sudo. I feel more comfortable with this new layout. Authorization is still weird on my iMac/Mojave, however. I had to sudo tar xvf the downloaded node archive, but fortunately I became owner of the unpacked material.

Back to my Air/Lion. I had also reinstalled Node here, and unpacking an archive didn’t require any sudo. Couldn’t I deploy Joplin more or less the same way, circumventing nmp? I didn’t find an authorized way to do that. Couldn’t I simply transplant the installation on iMac/Mojave/Node-12.16.1 to Air/Lion/Node-11.15.0? No, wrong sqlite3 binding (v72, should be v67).

So I mobilized a third machine, an Air/Mojave, elegantly installed Node 11.15.0 there, tried nmp again, and yes, I had a working Joplin Terminal on that machine (no handshaking problem here). This could be a compatible version, suitable for transplantation to the Air/Lion. And indeed, this time it started to breath. The GUI version cannot live on this place, BTW. Neither can Dropbox anymore. But I’m happy, it was a productive day.

What to think of this Frankenstein method? My lesson learned: always have a large collection of macs at your disposal.

You could also do this in the node_modules dir: npm rebuild --build-from-source sqlite3

Yep, as long as it gets the desired results -> :+1: