GROUPID not applied on mounted volume

[tomsquest]

Hi David,

I started using your image and I noticed a strange behavior with the GROUPID not being respected for the base directory.

Problem: after starting the container, my /storage folder is own by group 101 instead of 1000 (as per the GROUPID).
The USERID is applied correctly.

$ stat /storage/
  File: /storage/
Access: (0775/drwxrwxr-x)  Uid: ( 1000/     tom)   Gid: (  101/systemd-journal)

The container is started with -p (full docker-compose.yml)

version: '3.4'

services:
  samba:
    image: dperson/samba
    environment:
      - TZ=Europe/Paris
      - USERID=1000
      - GROUPID=1000
    ports:
      - "137:137/udp"
      - "138:138/udp"
      - "139:139/tcp"
      - "445:445/tcp"
    tty: true
    volumes:
      - /storage:/public
    command: '-r -p -s "public;/public;yes;no;yes"'

I can reproduce the permission problem with chmod tom:tom /storage and restarting the container.
(I remove the read_only: true option I was using and still the same behaviour).

Thanks a lot,
Tom

[tomsquest]

I took the time to read samba.sh and on this line, chown is not applied to the group:

chown -Rh smbuser. $i

Could this be the cause and the solution?

[dperson]

Thanks for the report, I had a SNAFU in the scripts. The wrong group was being used by samba.

FYI, the . at the end of the username tells it to assign the primary group for the user as well.

[tomsquest]

Thanks for taking the time to fix it.

And thanks for sharing the info about the . in chown.

[raqbit]

Just found this issue after half an hour of debugging, apparently I was relying on the fact that the default group used was users.

My volume is mounted read-only & the folder on the host gives read access to the users group.

Turns out both users groups (inside and outside the container) shared the same gid so I never noticed this quirk until this fix was released & I recreated my container.