From @flussence on Sat Oct 22 2016 02:22:44 GMT+0000 (UTC)
I’m gathering together a few pieces of info on the FUSE interface here to hopefully save others the head-scratching it caused me. It can seem nonsensical or even broken at first glance, but it does actually work as intended once you know why certain things happen.
ipfs mount takes a really long time
The mount process tries to resolve /ipns/local on the filesystem to whatever you’ve put in ipfs name publish previously, which may end up timing out or incurring network delays for whatever reason.
One way to avoid that is re-running your last publish command, or putting the empty node there if you don’t care (ipfs name publish QmUNLLsPACCz1vLxQVkXqqLX5R1X345qqfHbsf67hvA3Nn).
ls -l showing question marks for the mountpoints
FUSE on Linux is strict by default, and won’t let users see each other’s mountpoints at all. Even if you’re root:
To override that you need to put user_allow_other in /etc/fuse.conf, and on the IPFS side do ipfs config --json Mounts.FuseAllowOther true. No need to restart the daemon, just umount them and then ipfs mount again.
ls -l showing weird permissions
Supposing you’ve just got past the previous point, now you’ll see something like this:
d--x--x--x 1 root root 0 Oct 21 19:49 ipfs
d--x--x--x 1 root root 0 Oct 21 19:49 ipns
Read permission isn’t set or needed here because that’s for reading the directory, not accessing files within it. That’s what the +x does. Reading a directory that can contain any valid ipfs hash would be impossible unless you were on a controlled, closed network.
The /ipns mountpoint
I’d recommend not using this — go umount ipns and use the ipfs name commands instead. But if you still want to…
/ipns/local is a symlink pointing to your node’s local ID, so you can readlink it to get at that easily.
/ipns/${Your ID} is a visible directory you can write to. Or sometimes it’s a file. It depends what you last published using the CLI. You can’t switch between the two types from this interface.
Deleting files from the directory is possible but the deletions won’t stick.
If it’s a file, most operations will malfunction.
/ipns/${Someone Else's ID} will behave as a symlink, but doesn’t currently resolve correctly.
I believe I’ve taken the necessary steps for the permissions, with the exception of having a fuse group and being a part of it. With the FUSE stuff that comes packaged with Archlinux, there is no FUSE user/group. Anyway, here’s the behaviour I’m experiencing:
tomato@think01:~ $ ls -lah / | grep ipfs
drwxr-xr-x 1 tomato tomato 0 Jun 28 17:37 ipfs
tomato@think01:~ $ cat /etc/fuse.conf | grep allow_other
# Allow non-root users to specify the 'allow_other' or 'allow_root'
user_allow_other
tomato@think01:~ $ ipfs mount -f /ipfs -n /ipns
IPFS mounted at: /ipfs
IPNS mounted at: /ipns
tomato@think01:~ $ ls -lah / | grep ipfs
d--x--x--x 1 root root 0 Jun 28 01:21 ipfs
tomato@think01:~ $ ls -lah /ipfs
ls: reading directory '/ipfs': Operation not permitted
total 0
tomato@think01:~ $ sudo ls -lah /ipfs
ls: reading directory '/ipfs': Operation not permitted
total 0
The FAQ question here would be getting permissions errors when trying to explore inside the mount with ls and whatnot (different to ls'ing to check the permissions of the mount dir itself).
@leerspace, are you sure you can’t ls inside /ipfs under no circumstances? Then, what’s the purpose of mounting at all?
I hoped to use the mounted directory to serve static files via Nginx. However, I’m getting the same ls: reading directory '/ipfs': Operation not permitted as @tomatopeel.
I followed this guide (but needed to create the fuse group manually):
I’m almost certain. What would you expect to show up as the output of ls /ipfs? The number of ipfs hashes is huge.
The point of the fuse mount is that your traditional applications can load content from IPFS without the maintainers needing to add support for IPFS. For example, let’s say that I have my entire music library at Qmmusichash (not a real hash, of course); I can then either tell my existing music client to look in /ipfs/Qmmusichash for my music or create a sym-link to /ipfs/Qmmusichash and point my music client to the sym-link – updating the symlink as needed to point to the latest /ipfs/ path.
That’s exactly what I was thinking about. I wanted to point static.mysite.com via Nginx to /ipfs, hoping there are all files of my local IPFS node in a flat structure.
But if even ls can’t access this directory, how should other applications?
Why not add all of the files for your site to an IPFS directory and then point your site to /ipfs/hash where hash is the multi hash for the directory containing your website?
Because only user uploaded images are going into IPFS and therefore the directory changes very frequently.
Also, I don’t want my node to be exposed with :5001 or :8080 to the public. Otherwise it can be abused.
I’m now going the way Decentraland is going with their IPFS-Node(aka proxy). This will communicate with the frontend and forward files to IPFS. And since the --mount option is not working as I hoped, my proxy will copy the files also to a AWS S3 bucket. The frontend will then only access those static files while they’re also managed within IPFS under the hood.
