Host System
OS: Linux Mint
VERSION 21.1 (Vera)
*Note, as part of this process I may upgrade to Mint 21.3 unless I find reason otherwise
UBUNTU_CODENAME: jammy
DOCKER CONTAINER MAPPED FOLDERS: /home/user/.docker (eg. .docker/appdata, .docker/logs)
NAS STORAGE: Mapped via CIFS on host system /mnt/NAS
Docker Details
Server:
Server Version: 25.0.4
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Cgroup Driver: systemd
Cgroup Version: 2
Runtimes: io.containerd.runc.v2 nvidia runc
Default Runtime: runc
Init Binary: docker-init
containerd version: ae07eda36dd25f8a1b98dfbf587313b99c0190bb
runc version: v1.1.12-0-g51d5e94
init version: de40ad0
Docker Root Dir: /var/lib/docker
Debug Mode: false
Portainer Edition
Business Edition
Version: 2.19.4
After using Docker and Portainer for around a year now, the learning process and changes to the system I have made are now causing issues, especially related to deleting and sometimes even starting/stopping Stacks from within Portainer. The below is one of the main errors I receive:
failed to remove a stack: Error response from daemon: <html><body><h1>403 Forbidden</h1> Request forbidden by administrative rules. </body></html>
I have been able to work out that it is to do with how Docker is installed (‘root’ install) and some messiness around the UID/GIDs being used to start the daemon and Portainer (currently using the ‘main’ user 1000).
To fix this, I want to completely remove Docker from my system (keeping my 'appdata' folder located in /home/user/.docker and a backup of my Docker-Compose/Portainer Stack files for easy redeployment), then reinstall Docker to run in Rootless mode (https://docs.docker.com/engine/security/rootless/) as a new user (d-docker).
While I don’t want to make a new user for every container, I do want to separate them for better security and access.
Group:
10000 - container-super (Super users for containers that have direct access to the now proxied DOCKER_HOST)
11000 - container-nas (for containers that have local filesystem, NAS access and shared folders such as logs and databases)
12000 - container-local (for containers that ONLY have local filesystem access)
13000 - container-nopriv (for containers with very limited or no filesystem access beyond their own necessary config folder)
Users would then be something like:
G:10000 U:10001 'd-docker' (used to install and run the daemon and with created Home Directory)
G:10000 U:10002 'd-portainer'
G:10000 U:10003 'd-diun'
G:11000 U:11001 'd-aars' (for Radarr, Sonarr etc)
And then access via setfacl
/home/d-docker/.docker/* would be set with full read/write access for group 10000 via sudo setfacl -R -P -m g:10000:rwx (and my main user 1000 would also have full read/write access)
/home/d-docker/.docker/logs would then be set with full read/write access for group 11000 via sudo setfacl -R -P -m g:11000:rwx
While this might be a bit fiddly at first, it can be managed from within Linux with relative ease (I believe).
I would then launch Portainer via sudo -u d-portainer 'docker-compose up -d'
With the below:
version: "3.9"
services:
portainer:
image: portainer/portainer-ee:latest
container_name: portainer
environment:
- PUID=10001
- PGID=10000
From there, I can set the PUID and PGID as needed within each stack/container compose file.
So my question is… Will this work? Will this help me keep permissions a little more secure but also still work?