different GID for www-data when use with another debian cointainer
Closed this issue · 2 comments
Please add note about different GID for www-data between alpine and debian. I used this container with another one (based on debian11-slim, create web server with apache2, and my app in php; my php script generate image thumbnails ftom samba shate data)... So I found permission problem with this sharing setup.
My easy fix is replace force group from www-data to xfs and resolve my issues.
services:
# my cointainer
web:
links:
- db
depends_on:
- db
image: myregistry:5000/avst/debian11-php:1.2.3
container_name: mycointainer-web
hostname: mycointainer
restart: always
healthcheck:
test: ["CMD", "curl", "-Ss", "http://localhost"]
interval: 30s
timeout: 5s
retries: 5
networks:
- default_mycointainer
ports:
- 0.0.0.0:80:80
- 0.0.0.0:9000:9000
#- 0.0.0.0:9091:9091 #pro debug supervisord lze zapnout web server
environment:
DB_HOST: mycointainer-mariadb #musí odpovídat hostname service db
DB_USER: ${DB_USER} #.env
DB_PASSWORD: ${DB_PASSWORD} #.env
volumes:
- ./data:/var/www/html/data
- /etc/localtime:/etc/localtime:ro
db:
image: mariadb:lts #10.11 - LTS 2/2028
container_name: mycointainer-db
hostname: mycointainer-mariadb #musí odpovídat env DB_HOST service web
restart: always
networks:
- default_mycointainer
healthcheck:
test: ["CMD", "healthcheck.sh", "--su-mysql", "--connect", "--innodb_initialized"]
interval: 10s
timeout: 5s
retries: 5
environment:
MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD} #.env
MARIADB_AUTO_UPGRADE: "yes"
volumes:
- ./avst-db-data:/var/lib/mysql #v případě změny oprávnění stačí použít: sudo chown -R $USER:$USER avst-db-data/
- /etc/localtime:/etc/localtime:ro
phpmyadmin:
links:
- db
depends_on:
- db
image: phpmyadmin/phpmyadmin:latest
container_name: mycointainer-phpmyadmin
hostname: mycointainer-phpmyadmin
restart: always
healthcheck:
test: ["CMD", "curl", "-Ss", "http://localhost/robots.txt"]
interval: 10s
timeout: 5s
retries: 5
networks:
- default_mycointainer
ports:
- 0.0.0.0:8080:80
environment:
PMA_HOST: db
UPLOAD_LIMIT: 2G
volumes:
- /etc/localtime:/etc/localtime:ro
samba:
image: ghcr.io/servercontainers/samba:latest
container_name: mycointainer-smb
hostname: mycointainer-smb
healthcheck:
test: ["CMD", "docker-healthcheck.sh"]
interval: 1m
start_period: 30s
timeout: 5s
retries: 5
restart: always
cap_add:
- CAP_NET_ADMIN
environment:
ACCOUNT_data: ${SMB_ACCOUNT_data} #.env
GROUP_xfs: 33 # replace www-data with xfs
GROUPS_data: xfs # replace www-data with xfs
UID_data: 1000 # must be same as UID in ACCOUNT_data
TZ: Europe/Prague
WSDD2_DISABLE: 1
SAMBA_VOLUME_CONFIG_data: |
[data]
comment = Data myapp
path = /shares/data
valid users = data
force user = data
force group = xfs # replace www-data with xfs
guest ok = no
read only = no
browseable = yes
create mask = 0775
directory mask = 0700
networks:
- samba
ports:
- 0.0.0.0:137:137
- 0.0.0.0:139:139/udp
- 0.0.0.0:445:445
volumes:
- ./data:/shares/data
- /etc/localtime:/etc/localtime:ro
networks:
default_mycointainer:
name: mycointainer_network
samba:
name: mycointainer_smb
Thanks for add note.
Hi there,
I'm currently not sure if I want to go that deep into the details of some special configurations of some users.
I think that when you're working with low digit user or group ids, you should know what you're doing and are able to find your own way around.
In the end it shouldn't matter what host OS you use etc.
you could for example mount your samba share on the host os, and use of uid and gids mapping mount options.
so your samba could use 1000 as gid and uid and you mount with something like
sudo mount -t cifs -o username=${USER},password=${PASSWORD},uid=$(id -u),gid=$(id -g),forceuid,forcegid, //docker-samba/folder /containers/othercontainer/data
you're currently try to hack a buch of software together, and this usually means that you should know what you're doing
I noticed that there are many users who do hacks like that, but my understanding of this container is a general setup of a samba system, with focus on a normal user/family/(small) company which wants a fileserver/timemachine backups etc.
Also from a container perspective, it doesn't know anything about your host or other container users/groups etc.
if you need a special uid and gid, which you're not able to set, due to alpine system also using it, you're correct you need to use the alpine container group with this id (as you did) or since it's not an official api of this container which might change due to alpine os changes make a container which hacks your user config into it
Off course, I combine lot of docker cointainer together in one compose file and share data folder as docker volume ( mycointarner ./data:/var/www/html/data - samba ./data:/shares/data), Thete is more than one setup.
So i try be suporting.
If this info irelevant for your, please close without any add note.