Js-ipfs broke error `Unhandled Rejection (LockExistsError): Lock already being held for file: ipfs/repo.lock`

Any guy is using js-ipfs ? I got this error as below described.

Not sure any wrong with my code?

Unhandled Rejection (LockExistsError): Lock already being held for file: ipfs/repo.lock

My code is very brief and simple, just one little snippet copied from GitHub - ipfs/js-ipfs: IPFS implementation in JavaScript

App.tsx like below:

And info got from dev console as below.

If you’ve already initialised IPFS on a repo, it will lock it. If you’d like to test with multiple repos, you can use something like this:

await IPFS.create({repo: 'ok' + Math.random()});

To use a random repo. If you think it shouldn’t be locked, you should delete the local data, and it’ll create new data.

1 Like

Thanks for being here. Appreciate it.

If you’ve already initialised IPFS on a repo?

What do you mean by ‘initialised IPFS on a repo’, how and what I can do that?

Are you referring the below ‘repo’?


You can find more about the repo option here in the js-ipfs docs.

As for where it’s saved, for me, it’s in the same directory I’m running my commands from. I don’t know how your configuration works, or where that data goes. For me they’re saved in a directory, with the same name as the repo, assuming I used a custom one. As for not using a custom one, looks like the default location is usually ~/.jsipfs.
Hope that helps!

1 Like

Actually, I have no idea about the mechanism of js-ipfs, each web browser from the end user, must run one ipfs node, to navigate?

Uh, your end user will upload their file(s) to you web svr, like nginx, then you will upload these files to IPFS, through js-ipfs, right?

A great example of how js-ipfs works can actually be found on their homepage, I highly encourage you to check it out: https://js.ipfs.io/

Effectively, you can run a full IPFS node in browser using js-ipfs. I’m going to be working on an example of using js-ipfs to add data in an application context in the near future.

So understanding it’s a full node, you simply need to have the user add the file to their browser js-ipfs node, and from there if you want, you could have the user broadcast the resulting CID of the file to your nodes, and have them pin the CID for some time, which would help re-share the file if the user exits your app.

Typically if you’re not re-initialising IPFS multiple times in the same run, you’ll re-use the same repo. This means when the user returns to your website, the same IPFS repo will load, and they’ll begin re-sharing the file they added once again.

I hope this adds some clarity :sweat_smile:

1 Like

I occasionally find that, there is many indexed db.
For yesterday, await IPFS.create({repo: 'ok'+ Math.random()}) is good solution.
For today, I must find a better one.

Now, I understand the meaning.
Unfortunately, I did this foolish thing, re-initilising IPFS every some seconds.

1 Like

Before, in my imagination, the size of one IPFS node, will be hundreds of M or G.
The example will be B/S architecture? Using create-react-app to build?

IPFS nodes can vary in size, generally a browser node won’t be very big, unless the user is intentionally adding lots of data to their node. The example will be a P2P example, IPFS uses libp2p in the background, so most applications are focused on a p2p scenario, without really a main server. User adds data, other users can retrieve it. It’ll be detailed, and you could of course modify it further or just learn from it if you wanted it to do more.

I plan to have it feeling stable. So I want it to feel like you have the benefits of a server handling everything, without actually having to rely on centralisation.