New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ipfs add cannot add files owned by other users #7872
Comments
|
Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
Finally, remember to use https://discuss.ipfs.io if you just need general support. |
|
@jl6 ipfs should not have this restriction. Is it possible that you are running SELinux and this is a result of a security policy? To check the status of SELinux, run: Another thing you can try is to read the file from stdin: |
|
@gammazero I'm not running selinux: Feeding the file to ipfs on stdin, as you suggest, works. I can get a different error if I try adding a file which isn't owned by the current user and additionally is in a directory which isn't owned by the current user: That file is still readable by other programs: |
|
Does the -rwsrwxr-x |
|
Sadly not: |
|
@jl6 OK, I see the problem. You installed Snap packages have "confinement" which is either "strict" or "classic". You installed You have a few choices here:
|
Users who want to know how to install IPFS may not be aware of Snap's [confinement](https://snapcraft.io/docs/snap-confinement) behavior. So, I thought it useful to add a note someplace where they might see it before they install the Ubuntu Snap package. Hopefully, this can prevent issues like this one: ipfs/kubo#7872
|
That's it - thanks @gammazero |
jl6 commentedJan 20, 2021
Version information:
go-ipfs version: 0.7.0-ea77213e3
Repo version: 10
System version: amd64/linux
Golang version: go1.14.9
Description:
ptest.pdfis a file with -rw-rw-r-- permissions, but owned by a different user than the user executing the command.ptest.pdfcan definitely be read by the current user - tested by usingsha256sumto hash it.The command succeeds with a copy of the file in the same directory that has identical permissions but is owned by the user executing the command.
I believe the ownership of the file should not be a barrier to adding it to ipfs, provided the file can be read by the current user, although I'm happy to have this belief corrected if there is somewhere in the documentation that explains why.
The text was updated successfully, but these errors were encountered: