Diskover container do not allow running as root

[Carpe-Diem-Postero]

If you are new to Docker or this application our issue tracker is ONLY used for reporting bugs or requesting features. Please use our discord server for general support.

---

Expected Behavior

Diskover container should allow user to run as root (PUID and PGID 0)

Current Behavior

Tested on QNAP: If used PUID & PGID 1000 (primary user, administrator privileges), file crawler errors when trying to read "admin" user owned files (and for some reason, diskover web GUI crashes when this happens). "admin" owned files cannot be read, even if they have 770 permissions.

This behavior makes impossible to use Diskover on a QNAP when some files are owned by "admin" user. Admin in QNAP is PUID PIGD 0, and the only user with root permission.

But if you run container with PUID and PIGD 0 (admin user, which is the only user with permission to read everything), the container returns:

ERROR: [pool www] please specify user and group other than root ERROR: FPM initialization failed

Steps to Reproduce

1. set docker container to run with PUID PGID=0 credentials
2. run container

Environment

OS: QTS 4.4.1 CPU architecture: x86_64
How docker service was installed:

Docker service comes by default using container station (docker implementation in QNAP)

Command used to create docker container (run/create/compose/screenshot)

version: '2' services: diskover: image: linuxserver/diskover container_name: diskover environment:

• PUID=0
• PGID=0
• TZ=Europe/London
• REDIS_HOST=redis
• REDIS_PORT=6379
• ES_HOST=elasticsearch
• ES_PORT=9200
• ES_USER=elastic
• ES_PASS=changeme
• RUN_ON_START=true
• USE_CRON=true volumes:
• $[HOME]/diskover/config:/config
• /share/CE_CACHEDEV2_DATA/:/data ports:
• 80:80
• 9181:9181
• 9999:9999 mem_limit: 4096m restart: unless-stopped depends_on:
• elasticsearch
• redis elasticsearch: container_name: elasticsearch image: docker.elastic.co/elasticsearch/elasticsearch:5.6.9 volumes:
• ${HOME}/elasticsearch/data:/usr/share/elasticsearch/data environment:
• bootstrap.memory_lock=true
• "ES_JAVA_OPTS=-Xms2048m -Xmx2048m" ulimits: memlock: soft: -1 hard: -1 redis: container_name: redis image: redis:alpine volumes:
• ${HOME}/docker/redis:/data

Docker logs

https://pastebin.com/ZkqqTWWe

[shirosaidev]

Did you try adding user uid 1000 (default for the diskover container) to your volume mount directory group ownership? Try creating a user on your qnap with uid 1000 and add to the Admin group on your qnap or if you can't add to Admin group, set your directories to allow that new uid 1000 user to have permissions to all your directories and files that you want to index (the volume mount pointing to /data).

[Carpe-Diem-Postero]

UID 1000 user already exists, and all files are accesible to it through group permissions.

Current user is already UID 1000, and it belongs to "administrators" group (GID=0). It can read and write the admin owned files without any issue, as they are 770. It jus don't own them.

But for some reason, even if I launch the container as PUID=1000, crawler errors and crashes when tried to access files owned by admin user, even if UID 1000 user can actually rw them by Group Directive (both admin and user 1000 belong to administrators). If I chown those file to user 1000, then it works without crashing.

So, files with: "rw-rw-rw- user administrators" can be read, but files with "rw-rw-rw- admin administrators" cannot be read.

I think the problem is how QNAP manages permissions. There is no "sudo" command, and administrator group users do not really have full administrator rights. The only one that can is admin (UID=0).

[j0nnymoe]

I believe you'll need to create a non-admin user that has access to every share you want to crawl with diskover. When you add a user to the admin group on QNAP (and I assume other retail NAS units) this makes them a root user which causes issues with our containers.

[Carpe-Diem-Postero]

Ok, I think I got it:

If you have a user PID=1000 (i.e. "mainuser") that belongs to administrators group (GID=0), container will crash.

If you then create a new user group without admin rights (i.e. "diskovergid" with GID=1002), and make "mainuser" member of this group without taking it out from administrators group, you can simply launch the container with PUID=1000 & PGID=1002, it works, even if files are not readable to group "discoverid". It seems that PUID permissions take over PGID permissions (which is weird, because if you launch PUID=1000 & PGID=100 (everyone), container keeps crashing. It seems that "eveyone" group does not work)

That's a workaround, but it seems to work. Thanks.

I also have one question: Is there any documentation about usage in docker environment? for example, it seems that for diskover to find dupes, you must launch "diskover --finddupes", but how can I issue CLI commands to the container for specific tasks, like finding dupes?

[shirosaidev]

You have to shell into the container and run those commands from cli, for finddupes you run that as post command for diskover.py after the crawl finishes and index is done being built.

[Carpe-Diem-Postero]

It works! thanks for that insight :)

[nemchik]

Closing this. If you need any more help feel free to comment here or join our discord (link in the readme).