Por favor, veja a edição abaixo , pois o problema é com o uid / gid para sid mapping e mostra uma solução alternativa que ajudará a entender o problema mais rapidamente.
Temos uma máquina servidora Ubuntu 11.04 (vamos chamá-la de dados) associada ao Windows Domain com ferramentas fornecidas por igualmente aberto Até aí tudo bem, porque eu sou capaz de:
Assim, o próprio computador compreende quais grupos de domínio eu sou membro e posso manipular corretamente as permissões.
Mas o problema é quando eu quero acessar arquivos do compartilhamento de samba. O Windows parece não entender que estamos falando dos mesmos "administradores de domínio" ou de qualquer outro usuário / grupo de domínio.
A pasta inicial é ativada por ACL
Minha parte como está no 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
Até aí tudo bem, eu posso acessar o compartilhamento, uma vez que a pasta tem permissões de leitura / execução, bits definidos para "outros"
Então, vamos tentar acessar test_directory com o conjunto de permissões de domínio. Eu removi todas as permissões do Unix:
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/
Então, na máquina, se eu tentar
ls ./test_directory/
Obviamente, recebo
ls: cannot open directory ./test_directory/: Permission denied
Portanto, adiciono todas as permissões para "Admins. do domínio". (Eu poderia ter pulado o MYDOMAIN \ thing, porque MYDOMAIN é o domínio padrão para a máquina)
$ sudo setfacl -m g:MYDOMAIN\"Domain Admins":rwx ./test_directory/
Eu posso fazer as coisas no diretório
$ echo "yay" >> ./test_directory/test.txt
$ ls ./test_directory/
test.txt
Até aí tudo bem, os dados entendem os grupos de domínio.
Mas se eu tentar acessar esse compartilhamento na máquina windows (do powershell):
PS> whoami
mydomain\janis.veinbergs
PS> gci \data\home\test_directory
Get-ChildItem : Access to the path '\data\home\test_directory' is denied.
Agora, a partir de dados, adicionarei permissões para outras pessoas, para poder acessar essa pasta no Windows:
$ sudo chmod o+rx ./test_directory/
Agora, no Windows, posso ver arquivos:
PS> gci \data\home\test_directory
Directory: \data\home\test_directory
Mode LastWriteTime Length Name
---- ------------- ------ ----
----- 2012.02.06. 14:56 4 test.txt
Agora eu posso ver as permissões na janela de propriedades (localizada, mas você pode ter a ideia)
EumeperguntoporquemostraUnixGroup\domain^adminsemvezdeMYDOMAIN\domain^admins?Oqueeusintofaltaaquiecomofazerissofuncionar?
Euencontreiumasoluçãoalternativaeumapossívelcausa,masnãoseicomoresolver.Acontecequealgunsmapeamentoserradosentreosidsestãoacontecendo.
Seeuolharomapeamentodesid-to-gidcomowbinfoparaogrupoMYDOMAIN\AdminsdoDomínioeuachoqueounixgidmapeadoé10010.Eseeudefinirpermissõesusandogid,nãoonome,aspermissõesfuncionameowindowscompreende-os:
$sudosetfacl-mg:10010:rwx./test_directory/Quandoeuenumeroaspermissõesnoformatonumérico,paraverogideosid,vejoquequandoaspermissõesdeconfiguraçõescomoMYDOMAIN\"Admins. do domínio", ele realmente usa um GID diferente
$ 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::---
Eu então olhei para minha configuração de idmap em 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
Eu vejo que o gid da entrada do ACL 1319633408 não entra no escopo definido. Então eu tentei estender o escopo para 10000-3355443100, reiniciado smbd, mas ainda não funcionou.
Então, agora eu tenho uma solução alternativa, para definir permissões usando gid, sid, mas isso não é amigável. O que devo fazer para corrigir isso?
Acontece que eu ainda precisava instalar o suporte do mesmo modo -cifs.
Foi uma questão de executar estes comandos:
$ /opt/likewise/bin/samba-interop-install --install
$ service smbd restart
$ service winbind restart
Créditos para Do mesmo modo Open 6 & Samba - Um melhor servidor de arquivos de código aberto
Agora, ao mapear SID para GID, eu recebo o GID correto da mesma forma que o curto 10010:
sudo wbinfo -n "Domain Admins"
<i get long SID: S-...-512>
wbinfo -Y S-...-512
1319633408
Uma sugestão: Da mesma forma Centrify não gosta de citações em torno de nomes com espaços. Você deve estar usando uma barra invertida para anotar o grupo. Então, quando eu estiver fazendo referência ao meu grupo do Windows Domain Admins no Debian usando o Likewise Open, eu escreveria %Domain\ Admins . Você pode tentar isso e ver se agora atribui corretamente o GID?
Eu tenho uma máquina de reposição que posso instalar o Likewise Open on, vou usá-la para recriar o seu problema e criar uma nova resposta. Desculpe pela confusão!