Find the answer to your Linux question:
Results 1 to 4 of 4
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1

    New inode in Samba get a wrong group


    On a Ubuntu 16 system Samba is enabled.
    The smb.conf file is:
    [global]
    workgroup = buziness
    realm = buziness.local
    security = ADS
    restrict anonymous = 2
    smb ports = 445
    template shell = /bin/bash
    winbind separator = ^
    winbind enum users = Yes
    winbind enum groups = Yes
    winbind use default domain = Yes
    idmap config * : range = 10000-20000
    idmap config * : backend = tdb


    [klanten]
    path = /var/local/customers
    valid users = (AT)cusers (AT) for at-sign
    force group = cusers
    group = cusers
    read only = No
    create mask = 0777
    directory mask = 0777
    directory mode = 0777
    force directory mode = 0777

    When I create from Windows 10 a new folder or file the group on the Ubuntu systems is indeed "cusers".
    But sometimes the group becomes "staff".
    What can be the reason this problem?
    Can I debug the Samba behaviour in choosing the group?

  2. #2

    reproducible with newgrp in bash

    Quote Originally Posted by linuxlion View Post
    On a Ubuntu 16 system Samba is enabled.
    The smb.conf file is:
    [global]
    workgroup = buziness
    realm = buziness.local
    security = ADS
    restrict anonymous = 2
    smb ports = 445
    template shell = /bin/bash
    winbind separator = ^
    winbind enum users = Yes
    winbind enum groups = Yes
    winbind use default domain = Yes
    idmap config * : range = 10000-20000
    idmap config * : backend = tdb


    [klanten]
    path = /var/local/customers
    valid users = (AT)cusers (AT) for at-sign
    force group = cusers
    group = cusers
    read only = No
    create mask = 0777
    directory mask = 0777
    directory mode = 0777
    force directory mode = 0777

    When I create from Windows 10 a new folder or file the group on the Ubuntu systems is indeed "cusers".
    But sometimes the group becomes "staff".
    What can be the reason this problem?
    Can I debug the Samba behaviour in choosing the group?

    =============================================

    I can reproduce this problem now in bash with newgrp.
    staff is a locale group
    cusers is not a locale group but a group in de Domain Controller.

    # id
    uid=0(root) gid=0(root) groups=0(root)
    # newgrp cusers
    # id
    uid=0(root) gid=10018(cusers) groups=10018(cusers),0(root)
    # mkdir test_directory
    # ls -ld test_directory
    drwxr-sr-x 2 root staff 4096 Oct 25 14:58 test_directory
    # grep staff /etc/group
    staff: x:50:
    # wbinfo --group-info cusers
    cusers: x:10018

    Why is the group of the directory staff instead off cusers?

  3. #3
    More experiments show me that if an inode is created, the group of the new inode is the (effective) group of the process that create the inode, but only if the parent directory has not "s bit" in the group permissions.
    But if the parent directory has a "s bit" on the group, the new inode get the group of the parent directory.

    # id
    uid=0(root) gid=10018(cusers) groups=10018(cusers),0(root)
    # ls -ld .
    drwxrwxrwx 701 root staff 20480 Oct 26 10:03 .
    # mkdir test_dir1
    # ls -ld test_dir1
    drwx-r-xr-x 2 root cusers 4096 Oct 26 10:47 test_dir1

    # chmod g+s .
    # ls -ld .
    drwxr-sr-x 2 root staff 4096 Oct 26 10:48 .
    # mkdir test_dir2
    # ls -ld test_dir2
    drwxr-sr-x 2 root staff 4096 Oct 26 10:49 test_dir2

    Problem solved.

  4. $spacer_open
    $spacer_close
  5. #4
    -->
    Can I call this a bug or "lack of functionality" that, Samba only execute a set-group(cusers) and create a new new inode?
    A "force group = cuers" would give a new inode with realy the goup "cusers" and not only if the S-bit is not set on the group of the parent directory.
    Samba would execute a chgrp(cusers) to yield a new inode really has the group "cusers".

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •