mirror of
https://github.com/ArchiveBox/ArchiveBox.git
synced 2026-04-25 17:16:00 +03:00
[GH-ISSUE #1304] Bug: ArchiveBox doesn't work on NFS/SMB/FUSE drives that disallow root ownership or have root_squash set #2311
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#2311
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 @gnattu on GitHub (Dec 30, 2023).
Original GitHub issue: https://github.com/ArchiveBox/ArchiveBox/issues/1304
Describe the bug
If the docker-entry point failed to chown the archive folder, it quits immediately, so that the container does not run at all, make it impossible to run archivebox with an nfs-mounted volume as the archive folder.
I'm currently using this with a modified entrypoint which removed the line to chmod everything under DATA dir.
Steps to reproduce
Create an NFS volume with docker:
docker volume create --driver local --opt type=nfs --opt o=addr=[ip-address],rw --opt device=:[path-to-directory] [volume-name]Use this as the archivefolder in docker-compose.yml:
- volume-name:/data/archiveStart container. The conatiner quit right after it failed to chown the nfs mounted folder
Screenshots or log output
ArchiveBox version
@pirate commented on GitHub (Jan 1, 2024):
This only happens if your NFS volume disables or remaps permissions. The solution is not to remove the chmod but rather to set PUID & PGID environment variables to the same values that your NFS server enforces.
@gnattu commented on GitHub (Jan 1, 2024):
This is not always do-able because my server enforces the owner group id to 0 for all files and in this case, you cannot just set PGID=0 in env to fix this issue because you will have to allow root access for this NFS client as well. The PUID is already set to the correct value and that PUID does have read/write permission in the mounted dir. (And actually, the owner of the folder)
@pirate commented on GitHub (Jan 3, 2024):
hmm that's somewhat usual but I guess I can allow PGID=0.
I just pushed a commit to
:devto remove the PGID!=0 check, can you try it out?You can get it with
docker pull archivebox/archivebox:devor follow these instructions: https://github.com/ArchiveBox/ArchiveBox#install-and-run-a-specific-github-branch@gnattu commented on GitHub (Jan 3, 2024):
The strange thing is, even after set
PGID=0usingarchivebox/archivebox:dev, the container still failed withchown: changing ownership of '/data/archive': Operation not permitted.@pirate commented on GitHub (Jan 3, 2024):
Ah it looks like you're using the
root_squashoption on the server. This prevents allchowncalls from working, and is unfortunately not easily supported by ArchiveBox at the moment.AB in Docker starts running as root to create the data dir and set it up correctly, so when it drops down to a sub-user with fewer permissions it wont be able to modify the
root_squashedfiles it just created as they'll now be owned by the NFS anonymous/nobody user. If you're able to disable that option on the server or setno_root_squash, it should work.The security benefit that
root_squashprovides is limited anyway, as root on NFS is effectively able to impersonate any UID. root_squashing only prevents a specific SUID escalation attack but doesn't stop clients from impersonating other users.https://superuser.com/questions/1737302/root-squashing-for-nfs-and-smb-clarification
https://serverfault.com/questions/88114/cant-modify-or-chown-files-on-readynas-nfs-share
@jamesob commented on GitHub (Jan 4, 2024):
In my case, the fix here was to disable
root_squashon my NFS-via-ZFS share (on the NAS server), like so:and then verify that the NFS server exports reflects the new option with
# exportfs -v. I then recreated the archivebox docker container and stopped getting this permission error.