The IPFS daemon runs under the ipfs user.
If you want to access IPFS content from the system service you should use the HTTP API.

Example:

ipfs --api /ip4/127.0.0.1/tcp/5001 version

Or you can always init a repo for your user in the respective home directory.

Well, yes, you can do that. That has the same effect as setting the config file, which also points the command-line tool at that address.

What I'm saying is there's no point in enabling the daemon without doing so, and therefore it makes sense to make it the default target for the command. If you'd prefer adding a wrapper script that sets --api, I can do that.

Sorry for the delay :)

Maybe I have the wrong idea how your setup looks like.
When running ipfs under a user (in the service default it is ipfs) the repo is read-only for other users since
.ipfs/blocks and .ipfs/datastore are 755 and .ipfs/keystore is 700. So setting IPFS_PATH for other users allows them only to read data, so most IPFS commands will not work (ipfs add etc.).
If one wants to write data, the clean solution would be to use the HTTP API or to create a repository within $HOME and a systemd user unit which starts a dedicated daemon for that user if needed (listening on different ports or even in a separate network namespace).

Wrapping ipfs to include the local api is an option - however it will only work for this specific use case (needs to be overwritten for others). Bear in mind that this also changes the expected behavior (ipfs has its data in ~/.ipfs vs api contacts the system daemon automagically).

As for the IPFS_PATH, I don't think that this is a good idea - maybe someone else has an opinion.

I'll have to check, but I think I was able to add files as well.

The situation I'm trying to avoid is, basically:
I set services.ipfs.enable=true, but ipfs doesn't work unless I disable it. WTF?

...that is to say, at the moment, enabling the daemon is worse than useless. It takes over IPFS' desired ports, but the daemon isn't accessible unless you explicitly ask for it; a level of understanding that the average user won't have.

From reading the IPFS design docs, it also seems like the intention is to have a single system-wide daemon rather than per-user daemons. (Which won't work, because ports aren't scoped per-user.)

Just as feedback: I'm running the ipfs service on my notebook and I aliased alias ipfs='ipfs --api /ip4/127.0.0.1/tcp/5001' ... and it works for me (tm).

I wasn't aware of this PR before, I just created #25531. This fix here doesn't work I'm pretty sure, since environment.variables can't be set from a module as by my testing. In my PR I'm creating a wrapper around ipfs with IPFS_PATH set. I think that's the better approach to it instead of using the --api option in my opinion. I'd really like this to get fixed, since the current dataDir config option doesn't do anything useful.

I'm not sure about the directory permissions, I'll still have to test ipfs add (when I got it built again). I think it's reasonable to allow any user in the ipfs group to have full access to the system wide daemon for now. I believe the developers of ipfs themselves aren't really certain on how multi-user systems are going to be handled.

I think this PR should probably be closed since the merging of #25531 allows me to simply run ipfs add and have it be hosted.