Please see edit below, as it turns out that the problem is with uid/gid to sid mapping and shows a workaround that will help understand the problem more quickly.
We have a Ubuntu 11.04 server machine (lets's call it data) joined to Windows Domain with tools provided by likewise-open So far so good, because i am able to:
- Log on to machine with AD credentials
- Set permissions for files and folders with extended ACLs and they work. So by setting "Domain Admins" permission on the folder, i can log onto machine with different domain admin account and access that folder.
So the computer itself understands which domain groups i am member of and can correctly handle permissions.
But the problem is when i want to access files from samba share. Windows doesn't seem to understand that we are talking about same "Domain Admins" or any other domain user/group.
Details
The home folder has is acl-enabled
My share as it's in smb.conf:
[home]
path = /home/local/MYDOMAIN
browsable = yes
guest ok = no
read only = no
writeable = yes
valid users = MYDOMAIN\Administrator, @MYDOMAIN\"Domain Users", @MYDOMAIN\"Domain Admins"
write list = @MYDOMAIN\"Domain Users", @MYDOMAIN\"Domain Admins"
nt acl support = yes
create mask = 700
directory mask = 700
hide dot files = yes
So far so good, i can access the share given that folder has read/execute permissions bits set for "others"
So lets try to access test_directory with domain permissions set. I remove any unix permissions:
janis.veinbergs@data:/home/local/MYDOMAIN$ whoami
janis.veinbergs
janis.veinbergs@data:/home/local/MYDOMAIN$ id janis.veinbergs
...1319633408(domain^admins)...
janis.veinbergs@data:/home/local/MYDOMAIN$ cd /home/local/MYDOMAIN
janis.veinbergs@data:/home/local/MYDOMAIN$ sudo chown root:root ./test_directory/
janis.veinbergs@data:/home/local/MYDOMAIN$ sudo chmod 700 ./test_directory/
So on the machine, if i try
ls ./test_directory/
Obviously, i get
ls: cannot open directory ./test_directory/: Permission denied
So i add all permissions for "Domain Admins". (I could have skipped the MYDOMAIN\ thing, because MYDOMAIN is the default domain for the machine)
$ sudo setfacl -m g:MYDOMAIN\\"Domain Admins":rwx ./test_directory/
I can do things in the directory
$ echo "yay" >> ./test_directory/test.txt
$ ls ./test_directory/
test.txt
So far so good, data understands domain groups.
But if i try to access that share on windows machine (from powershell):
PS> whoami
mydomain\janis.veinbergs
PS> gci \\data\home\test_directory
Get-ChildItem : Access to the path '\\data\home\test_directory' is denied.
Now, from data, i'll add permissions for others, so i can access that folder from windows:
$ sudo chmod o+rx ./test_directory/
Now, from windows, i can see files:
PS> gci \\data\home\test_directory
Directory: \\data\home\test_directory
Mode LastWriteTime Length Name
---- ------------- ------ ----
----- 2012.02.06. 14:56 4 test.txt
Now i can view permissions in properties window (localized, but you can get the idea)
I wonder why it shows Unix Group\domain^admins rather than MYDOMAIN\domain^admins ? What am i missing here and how to make it work?
EDIT: Found a workaround
I'v found a workaround and possible cause but don't know how to resolve It turns out that some wrong mapping between id's are happening.
If i look up the sid-to-gid mapping with wbinfo for MYDOMAIN\Domain Admins group i find that the mapped unix gid is 10010. And this if i set permissions using gid, not the name, the permissions works and windows understands them:
$ sudo setfacl -m g:10010:rwx ./test_directory/
When i enumerate permissions in numerical form, to see gid's and sid's, i see that when settings permissions like MYDOMAIN\"Domain Admins", it actually uses a different GID
$ getfacl -n ./test_directory/
# file: test_directory/
# owner: 0
# group: 0
user::rwx
group::r-x
group:10010:rwx <-- this is the actual GID mapping for MYDOMAIN\\"Domain Admins" group (setfacl -m g:10010:rwx) and it works when browsing share with windows
group:1319633408:rwx <-- this entry is when setting permission like setfacl -m g:MYDOMAIN\\"Domain Admins":rwx
mask::rwx
other::---
I then looked at my idmap configuration in smb.conf:
idmap domains = ALL
idmap config ALL:backend = lwicompat_v4
idmap config ALL:default = yes
idmap config ALL:readonly = yes
idmap uid = 10000-33554431
idmap gid = 10000-33554431
I see that the gid from ACL entry 1319633408 doesn't go into the defined scope. So i tried extending scope to 10000-3355443100, restarted smbd, but it still didn't work.
So now i have a workaround, to set permissions using gid's, sid's, but thats not user friendly. What should i do to fix this?
It turns out that i still had to install likewise-cifs support.
It was a matter of executing these commands:
Credits to Likewise Open 6 & Samba - A Better Open Source File Server
Now when mapping SID-to-GID, i get back the correct GID likewise uses instead of the short one 10010:
One suggestion:
LikewiseCentrify doesn't like quotes around names with spaces. You should instead be using a backslash to note the group. So, when I am referencing my Windows group Domain Admins in Debian using Likewise Open, I would write%Domain\ Admins
. Can you try that and see if it now properly assigns the GID?Update:
After a good night's sleep, I realize that I am not using Likewise Open, but their competitor Centrify Express. It's not a vote of one over the other, but a clarification for others who could be reading the answer in the future.
I have a spare machine that I can install Likewise Open on, I will use it to recreate your problem and create a new answer. Sorry for the confusion!