Skip to content

Cifs acls on zfs problem

wordpress meta

title: 'CIFS ACLs on ZFS Problem'
date: '2012-11-12T05:44:22-06:00'
status: publish
permalink: /cifs-acls-on-zfs-problem
author: admin
excerpt: ''
type: post
id: 79
category:
    - 'Active Directory'
    - CIFS
    - Idmap
tag: []
post_format: []

Recently had an issue with a CIFS share on a Solaris 11 box. Still not sure how this happened but it turned out there was a weird Idmap mapping. Active Directory Group and members were correct and group had correct members. Yet still the users in this group could not write to the folder.

How to check identities in idmap:

# idmap show -cv rrosso@domain.com
winuser:rrosso@domain.com -> <span style="color: #0000ff;">uid:2147483651</span>
Source: Cache
Method: Ephemeral

# idmap show -cv DFS_Corp-CA-Dept-IT_rw@domain.com
wingroup:DFS_Corp-CA-Dept-IT_rw@domain.com -> <span style="color: #0000ff;">gid:2147483667</span>
Source: Cache
Method: Ephemeral

Lets just see how the mapping rules look:

# idmap list
add     winuser:*@domain.com  unixuser:*
add     wingroup:*@domain.com unixgroup:*
add     winuser:administrator@domain.com      unixuser:root
add     "wingroup:Domain Users@domain.com"    unixgroup:smbusers

The Active Directory Read-Write group that is not allowing the members to write to the folder:

# idmap show -cv DFS_Eng-CA-Dirs-Engineering-Bugzilla_rw@domain.com
wingroup:DFS_Eng-CA-Dirs-Engineering-Bugzilla_rw@domain.com -> <span style="color: #0000ff;">gid:2147484149</span>
Source: Cache
Method: Ephemeral

Looking at the folder called Bugzilla:
Current (broken) acl must be this one user:2147483813 if I look at the gid above. Not to mention the mapping is not for a group but for a user.

root@zfs001:/tank/dfs/engdirs/engineering/engineering# /bin/ls -v | more
d---------+ 16 2147483650 smbusers      17 Oct 12 14:14 Bugzilla
0:<strong><span style="color: #ff0000;">user:2147483813</span></strong>:list_directory/read_data/add_file/write_data
/add_subdirectory/append_data/read_xattr/write_xattr/execute
/read_attributes/write_attributes/delete/read_acl/synchronize
:file_inherit/dir_inherit:allow
1:<strong><span style="color: #008000;">group:2147483763</span></strong>:list_directory/read_data/add_file/write_data
/add_subdirectory/append_data/read_xattr/write_xattr/execute
/delete_child/read_attributes/write_attributes/delete/read_acl
/synchronize:file_inherit/dir_inherit:allow
2:<strong><span style="color: #008000;">group:2147483660</span></strong>:list_directory/read_data/read_xattr/execute
/read_attributes/read_acl/synchronize:file_inherit/dir_inherit
:allow

Looking at above something looks odd. Looking at the windows side we expect three groups to have permission here but spot the "user" listed in the first ACL.

Lets find the three id's. Left the grep wide open to find all uid and gid matching the number. But really we are just after the gid's:

# idmap dump -n | grep 2147483813
wingroup:Guests@BUILTIN ==      <strong><span style="color: #ff0000;">gid:2147483813</span></strong>
wingroup:DFS_Eng-CA-Dirs-Engineering-Bugzilla_rw@domain.com   ==      <strong><span style="color: #ff0000;">uid:2147483813</span></strong>

# idmap dump -n | grep 2147483763
winuser:Homey@domain.com     ==      uid:2147483763
wingroup:DFS_Eng-CA-Dirs-Engineering_rw@domain.com    ==      <strong><span style="color: #008000;">gid:2147483763</span></strong>

# idmap dump -n | grep 2147483660
winuser:Stewey@domain.com     ==      uid:2147483660
wingroup:DFS_Eng-CA-Dirs-Engineering_ro@domain.com    ==      <strong><span style="color: #008000;">gid:2147483660</span></strong>

# idmap dump -n | grep 2147484149
wingroup:DFS_Eng-CA-Dirs-Engineering-Bugzilla_rw@domain.com   ==      <strong><span style="color: #ff0000;">gid:2147484149</span></strong>

After we removed and recreated the group in AD. Might take a little bit to show up:

# idmap show -cv DFS_Eng-CA-Dirs-Engineering-Bugzilla_rw@domain.com
wingroup:DFS_Eng-CA-Dirs-Engineering-Bugzilla_rw@domain.com -> gid:2147484149
Source: Cache
Method: Ephemeral

# idmap dump -n | grep 2147483813
wingroup:Guests@BUILTIN ==      gid:2147483813
usid:S-1-5-21-1977730361-3076317898-4166923938-22371    ==      uid:2147483813

# idmap dump -n | grep 147484149
wingroup:DFS_Eng-CA-Dirs-Engineering-Bugzilla_rw@domain.com   ==      gid:2147484149

Permissions after re-applying from Windows:

# /bin/ls -dv Bugzilla/
d---------+ 17 2147483650 smbusers      18 Nov 12 20:12 Bugzilla/
     0:<strong><span style="color: #008000;">group:2147483763</span></strong>:list_directory/read_data/add_file/write_data
         /add_subdirectory/append_data/read_xattr/write_xattr/execute
         /delete_child/read_attributes/write_attributes/delete/read_acl
         /synchronize:file_inherit/dir_inherit:allow
     1:<strong><span style="color: #008000;">group:2147483660</span></strong>:list_directory/read_data/read_xattr/execute
         /read_attributes/read_acl/synchronize:file_inherit/dir_inherit
         :allow
     2:<strong><span style="color: #008000;">group:2147484149</span></strong>:list_directory/read_data/add_file/write_data
         /add_subdirectory/append_data/read_xattr/write_xattr/execute
         /read_attributes/write_attributes/delete/read_acl/synchronize
         :file_inherit/dir_inherit:allow

Just checking a new file we just created for good measure:

# /bin/ls -v | grep Test
d---------+  2 2147483740 smbusers       2 Nov 12 20:12 Test