mirror of
https://github.com/ArchiveBox/ArchiveBox.git
synced 2026-04-25 17:16:00 +03:00
[GH-ISSUE #539] Question: ... How to fix Permission denied: '/data' #345
Labels
No labels
expected: maybe someday
expected: next release
expected: release after next
expected: unlikely unless contributed
good first ticket
help wanted
pull-request
scope: all users
scope: windows users
size: easy
size: hard
size: medium
size: medium
status: backlog
status: blocked
status: done
status: idea-phase
status: needs followup
status: wip
status: wontfix
touches: API/CLI/Spec
touches: configuration
touches: data/schema/architecture
touches: dependencies/packaging
touches: docs
touches: js
touches: views/replayers/html/css
why: correctness
why: functionality
why: performance
why: security
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ArchiveBox#345
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Prn-Ice on GitHub (Nov 16, 2020).
Original GitHub issue: https://github.com/ArchiveBox/ArchiveBox/issues/539
I'm following the setup instructions using
docker-compose.When I run
docker-compose run archivebox initI get
Please how can I fix this?
@pirate commented on GitHub (Nov 16, 2020):
sudo chmod -R 777 data@Prn-Ice commented on GitHub (Nov 16, 2020):
I get
chmod: changing permissions of 'data/': Operation not permittedI tried with sudo, but still get the same error when I run
docker-compose run archivebox init@kodxana commented on GitHub (Nov 19, 2020):
@Prn-Ice had that same issue. First delete existing data folder the create it again with
mkdir datacommand :)@pirate commented on GitHub (Nov 19, 2020):
that should not be necessary. I don't know why a
sudo chmod -R 777 datadoesn't work. What user are you running the docker-compose commands as, and what OS are you on?@Prn-Ice commented on GitHub (Nov 26, 2020):
I'm using docker on Fedora 33.
@pirate commented on GitHub (Nov 26, 2020):
@junpet commented on GitHub (Nov 27, 2020):
Similar here. I set
777to the volume folder, but I got:My
docker-compose.yml. I've tried with and withoutOUTPUT_PERMISSIONS, no luck.After setting
777.Edit (I'd like to clarify I did use
-R):After running
docker-compose run archivebox initI run with my user the
docker-composecommands. Hope this helps.@Prn-Ice commented on GitHub (Dec 1, 2020):
I tried setting 777 on the parent archivebox folder and no luck.
@fs111 commented on GitHub (Dec 4, 2020):
I am trying on debian stable and I have the same issue. Any pointers?
@pirate commented on GitHub (Dec 4, 2020):
sudo chmod -R 777 dataoutside the container should fix it, don't just set 777 on the parent folder, you have to recursively set it with-R.@Prn-Ice commented on GitHub (Dec 5, 2020):
I switched to manjaro, followed the same steps, got
Then deleted the data folder and created it again
mkdir data.After that
docker-compose run archivebox initran successfully.@junpet commented on GitHub (Dec 5, 2020):
@pirate I've used
sudo chmod -R 777 datain the first place, please see my error above. By the way I use Debian on my server, but I won't change my OS...@bdelwood commented on GitHub (Dec 21, 2020):
I am having the same issue on Arch. I have a similar setup to junpet; using a local-driver named volume. After running
docker-compose up -dordocker-compose run archivebox initthe mountpoint ownership will change toroot:rootno matter what it was before.@HeinWinToe commented on GitHub (Jan 8, 2021):
@bdelwood @junpet
You need to change owner.
Try it with
sudo chown {uid}:{gid} -R data. You can find your UID and GID usingidcommand.@pirate commented on GitHub (Jan 8, 2021):
I'm going to investigate changing the archivebox docker user in the Dockerfile to reduce problems like this with volume ownership. I've looked at how a few other projects do it and I think there's a way to fix the UID/GID within docker to be the same as the external user at runtime.
@bdelwood commented on GitHub (Jan 8, 2021):
@HeinWinToe I think this is an issue with the container changing permissions. I already
chown'ed the directories, but recreating the container sets ownership toroot:root@pirate Great. If I have time I may look into it. For example, linuxserver.io has some custom scripts to ensure permissions. From the build repo for linuxserver/plex, for instance, they have a script to ensure correct permissions.
@junpet commented on GitHub (Jan 9, 2021):
@HeinWinToe Still does not work. I set the correct owner and rights, I wrote above, but as @bdelwood mentioned, the container messes up everything and does not start.
@Mist-Hunter commented on GitHub (Jan 9, 2021):
Just chiming in to say I'm having the same issue on Debian + Docker. I'd be curious to hear from someone who has gotten it to work, as it fails immediately with 100% reliability when just following the quick-start instructions.
Thank you for your work on this, I'm only posting this comment in the event it helps, not as a complaint. I'm excited to try this out as I've been looking for a replacement for HTTrack for quite a while :)
@Mist-Hunter commented on GitHub (Jan 9, 2021):
It might not be relevant, as I'm no expert. But I notice that the quickstart guide shows
docker run -v $PWD:/data -it archivebox/archivebox initdocker run -v $PWD:/data -it archivebox/archivebox --versionWhich could be root, and if I run:
docker run -v $PWD:/data --user 1000:1000 -it archivebox/archivebox initIt fails to init. Is it possible that running the init as root, and then the main docker as user could have anything to do with this problem?
@Mist-Hunter commented on GitHub (Jan 9, 2021):
In case this helps anyone understand what I'm doing wrong (or right). Here's the code I ran to get it working for me.
Note: Port 8000 is taken on my computer, I'm not using /root ($PWD) for my data, and I've added a label and a remove statement at each step because otherwise I'm ending up with orphaned containers and random names at every step (docker run). I can't get it to work with --user 1000:1000, but it is now running (not ideally) as root. Add a -d flag so I get my command prompt back.
@pirate commented on GitHub (Jan 13, 2021):
FYI @Mist-Hunter you can use
docker run --rm ...instead of having to label and then manually rm after each step.I usually run docker commands as root in a root-owned dir on Ubuntu, or as non-root in a non-root dir on macOS, so it's possible it only works in those two cases and I neglected to test non-root docker on Linux. Will report back once I have it fixed, a bit swamped this week with other work though.
@alanfranz commented on GitHub (Jan 18, 2021):
I'm experiencing the same issue as @junpet on Ubuntu 18.04, latest docker-ce (20.10.2) and latest docker-compose.
I think that the underlying issue is that the docker entrypoint file https://github.com/ArchiveBox/ArchiveBox/blob/dev/bin/docker_entrypoint.sh tries to do some magic to drop privileges. But it probably gets something wrong and/or sharing the volumes between multiple containers does something bad to the permissions.
My workaround includes using POSIX ACLs, so you can retain access from the current user
Annotate the two uids. They are 122 and 999 on my box, substitute as necessary.
Everything should work properly now.
@johnmaguire commented on GitHub (Jan 20, 2021):
Thank you so much, this is exactly what I was hoping for.
@pirate I'd love if it supported PGID/PUID env vars like some other Dockerfiles do (e.g. I think all linuxserver ones? Maybe a good reference)
@pirate commented on GitHub (Feb 1, 2021):
This should be fixed now in the latest v0.5.4 release (including PGID/PUID support), please give it a try. Report back here if you have any problems and I can reopen the issue.
@junpet commented on GitHub (May 3, 2021):
Sorry for late answer, I had no time. Just tried to spin up, and its working (well, I haven't done anything, just running the container). Time to read the docs. Thanks your hard work!
@eightfiftytwo commented on GitHub (May 29, 2021):
Hello. I'm a new user following the quick start guide. Still having this issue on Fedora Server 34. Tried every solution in this thread but nothing worked. I'm a noob to docker so I have no idea where to even begin.
docker: moby-engine 20.10.6
docker-compose: 1.28.6
@eightfiftytwo commented on GitHub (May 29, 2021):
I tried it with SELinux disabled and it works now. Not sure whether or where to open an issue about this...
@snowshoes commented on GitHub (Mar 11, 2023):
same error nowadays, macOS Monterey 12.5, have tried everything mentioned in the post, but the problem persists.
I've already checked this post
https://github.com/ArchiveBox/ArchiveBox/issues/948
@ctp9 commented on GitHub (Jan 6, 2025):
Same issue here - setup script is unable to complete due to permissions error. And no, I am not logged in as root (I made a new account just for ArchiveBox and am logged in with default access permissions):
@pirate commented on GitHub (Jan 6, 2025):
You have to run ArchiveBox inside a new empty dir, you can't run it from inside your
/roothome folder @ctp9.Please open a new issue for any futher help as this one is very old ans was originally opened for an issue on v0.5.