Você está na página 1de 38

Samba, parte 2: Configurao avanada do Samba (atualizado)

http://www.guiadohardware.net/tutoriais/samba-configuracao-avancada/

Tutoriais
Na primeira parte do tutorial, falei sobre a instalao do Samba, cadastro dos usurios e
sobre a configurao usando o swat. Nesta segunda parte mergulharemos na
configurao manual do Samba, editando diretamente o arquivo smb.conf, mostrando
detalhes sobre as opes e apresentando exemplos de configurao funcionais.Carlos E.
Morimoto
24/06/2009
Clique aqui para ver a primeira parte
Como vimos na primeira parte do tutorial, a maior parte da configurao do Samba,
incluindo as configuraes gerais do servidor, impressoras e todos os
compartilhamentos, feita em um nico arquivo de configurao, o
"/etc/samba/smb.conf". Programas de configurao, como o Swat, simplesmente lem
este arquivo, "absorvem" as configuraes atuais e depois geram o arquivo novamente
com as alteraes feitas dentro da interface. Isso permite que o Swat coexista com a
edio manual do arquivo. Como comentei a pouco, o Swat remove todos os seus
comentrios e formatao (deixando apenas as opes), por isso muitos evitam us-lo.
Apesar disso, o formato do arquivo de configurao do Samba bastante simples e por
isso muitas vezes mais rpido e at mais simples editar diretamente o arquivo do que
faz-lo atravs do Swat. Ao instalar o Samba, criado um arquivo de configurao de
exemplo, com vrios comentrios. Assim como no caso do Squid, ele longo e difcil
de entender, por isso acaba sendo mais fcil renome-lo e comear com um arquivo em
branco, ou usar como base a configurao gerada atravs do Swat.
Vamos ento a uma segunda rodada de explicaes sobre a configurao do Samba,
agora editando diretamente o arquivo smb.conf e explorando com maior profundidade
as opes disponveis. Vamos comear com um exemplo simplista, onde temos um
nico compartilhamento de teste:
[global]
netbios name = Sparta
workgroup = Grupo
[arquivos]
path = /mnt/arquivos
comment = Teste
Como voc pode ver, o arquivo dividido em sees. A primeira sempre a seo
"[global]", que contm as opes gerais do servidor. Por enquanto, definimos apenas o
nome do servidor (netbios name) e o nome do grupo de trabalho (workgroup), que seria

o mnimo necessrio para colocar o servidor na rede. As demais opes (no


especificadas no arquivo) so configuradas usando os valores default. Se voc omitir a
opo "workgroup", por exemplo, o Samba vai reverter para o grupo "WORKGROUP",
que o padro.
Se quiser, voc pode tambm adicionar uma descrio para o servidor, o que feito
atravs da opo "server string" (adicionada dentro da seo [global]), como em:
server string = Servidor Samba
Duas dicas so que:
a) O default do Samba usar a string "Samba 3.0.24" (onde o "3.0.24" a verso usada)
como descrio quando a opo "server string" no est presente no arquivo.
b) Nas mquinas com o Windows XP, a descrio do servidor aparece antes do nome
propriamente dito, como em "Servidor Samba (Sparta)". importante levar isso em
considerao, j que, no final das contas, o que importa o que os usurios iro ver ao
navegar pelo ambiente de redes:

Abaixo da seo [global], inclumos sees adicionais para cada compartilhamento, que
o caso da seo "[arquivos]" que cria o compartilhamento de teste.
O "[arquivos]" indica o nome do compartilhamento, da forma como ele aparecer na
rede. Logo a seguir temos a linha "path", que diz qual pasta do servidor ser
compartilhada e a linha "comment" (opcional), que permite que voc inclua um
comentrio.
Sempre que alterar manualmente o smb.conf, ou mesmo alterar algumas opes pelo
Swat e quiser verificar se as configuraes esto corretas, rode o comando testparm.
Ele funciona como uma espcie de debug, indicando erros grosseiros no arquivo e
informando o papel do servidor na rede:

# testparm
Load smb config files from /etc/samba/smb.conf
Processing section "[arquivos]"
Loaded services file OK.
Server role: ROLE_STANDALONE
O "ROLE_STANDALONE" significa que o servidor foi configurado como um membro
normal do grupo de trabalho. possvel tambm fazer com que o servidor Samba atue
como um controlador de domnio, como veremos em detalhes mais adiante.
Em caso de erros no arquivo, o testparm ajuda a localizar o problema, indicando a linha
ou opo invlida, de forma que voc possa corrig-la. Veja o que acontece ao adicionar
um erro simples, usando a linha "wrritable = yes" no lugar de "writable = yes":
Unknown parameter encountered: "wrritable"
Ignoring unknown parameter "wrritable"
O Samba no diferencia o uso de maisculas e minsculas nas opes, de forma que
tanto faz escrever "writable = yes", "writable = Yes" ou "writable = YES". Entretanto,
muitos dos parmetros no so diretamente usados pelo Samba, mas sim repassados ao
sistema que, diferentemente do Samba, diferencia os caracteres. Um exemplo so as
localizaes de pastas a compartilhar. Se voc escrever "path = /mnt/Arquivos" (em vez
de "path = /mnt/arquivos"), o compartilhamento no vai funcionar, pois o sistema
reportar que a pasta no existe.
Alm do caractere "#", possvel usar tambm o ";" para comentar linhas. A principal
observao que voc no pode inserir comentrios em linhas vlidas (mesmo que no
final da linha), pois, ao fazer isso, toda a linha passa a ser ignorada pelo Samba. Neste
exemplo, o comentrio foi includo na linha "path", o que acaba por desativar o
compartilhamento completamente:
[teste]
path = /mnt/arquivos # Pasta compartilhada
comment = Compartilhamento que no funciona
O testparm tambm no indica o erro diretamente, j que ele tambm considera a linha
como um comentrio, o que pode lev-lo a perder um bom tempo tentando descobrir
onde est o problema. Ao incluir comentrios no arquivo, use sempre linhas separadas:
[teste]
# Pasta compartilhada
path = /mnt/arquivos

comment = Agora sim


As alteraes no arquivo so lidas periodicamente pelo Samba (o default so 3 minutos)
e aplicadas automaticamente. Isso permite que as mudanas de configurao sejam
aplicadas de forma suave, sem prejudicar o acesso dos usurios, o que importante em
um ambiente de produo. Para fazer com que as alteraes entrem em vigor
imediatamente, reinicie o servio do Samba, como em:
# /etc/init.d/samba restart
ou:
# service smb restart
A partir da, o compartilhamento estar disponvel. Ao tentar acessar o servidor atravs
do "Meus locais de rede" nos clientes Windows, voc receber um prompt de senha,
onde voc precisa fornecer um dos logins cadastrados no servidor usando o comando
"smbpasswd -a":

importante enfatizar que todos os usurios cadastrados no Samba precisam tambm


existir no sistema, por isso, antes de usar o comando "smbpasswd -a", voc deve usar o
adduser para criar o usurio. Como citei anteriormente, a soluo para casos em que
voc no deseja criar contas vlidas para todos os usurios criar usurios limitados
usando o comando "adduser --disabled-login --no-create-home usuario" ou "adduser -M
usuario".

Depois de logado, o cliente pode visualizar os compartilhamentos do servidor. Por


enquanto temos apenas o compartilhamento "arquivos", que mostra o contedo da pasta
"/mnt/arquivos" do servidor, mas ao longo do tutorial adicionaremos muitos outros
recursos ao servidor:

Ajustando as permisses de acesso


Samba, parte 2: Configurao avanada do Samba (atualizado)
Carlos E. Morimoto
24/06/2009
Com esta configurao, os clientes conseguem visualizar os arquivos da pasta
normalmente, mas ainda no conseguem gravar nos arquivos. Ao tentar salvar alguma
coisa na pasta, voc recebe uma mensagem de acesso negado:

Isso acontece por dois motivos. O primeiro que o default do Samba compartilhar
com permisso apenas para leitura. Como no dissemos nada sobre as permisses de
acesso do compartilhamento no arquivo de configurao, ele foi compartilhado usando
o default.
Para que o compartilhamento fique disponvel com permisso de leitura e escrita,
precisamos adicionar a opo "writable = yes" dentro da configurao do
compartilhamento, que ficar:
[arquivos]
path = /mnt/arquivos
writable = yes
comment = Teste
Muito provavelmente, mesmo depois de reiniciar o Samba voc continuar recebendo o
mesmo erro ao tentar gravar os arquivos. Dessa vez, o Samba autoriza a gravao, mas
ela ainda pode ser abortada se as permisses da pasta no permitirem que o usurio
grave arquivos. Se voc criou a pasta "/mnt/arquivos" como root, ento o default que
apenas ele possa gravar arquivos na pasta. Para permitir que outros usurios possam
gravar, necessrio abrir as permisses da pasta.
A esta altura, a lei do mnimo esforo diria para voc usar um:
# chmod 777 /mnt/arquivos

Obviamente, isso permitiria que os usurios gravassem na pasta. O problema que as


permisses ficariam escancaradas, a ponto de qualquer um, que tenha acesso ao servidor
(por qualquer meio) possa alterar os arquivos dentro da pasta, o que no nada bom do
ponto de vista da segurana.
No tpico sobre o Swat, vimos como criar um grupo usando o users-admin (systemconfig-users) e abrir as permisses da pasta apenas para os usurios que fazem parte
dele. Vamos ver agora como fazer isso via linha de comando.
O primeiro passo criar um grupo para os usurios que podero fazer alteraes na
pasta, usando o comando "groupadd". Eu prefiro criar grupos com o mesmo nome do
compartilhamento, para ficar mais fcil de lembrar, mas isso fica a seu critrio.
# groupadd arquivos
A partir da, voc pode adicionar usurios ao grupo usando o comando "adduser", nesse
caso especificando o usurio j criado e o grupo ao qual ele ser adicionado, como em:
# adduser joao arquivos
# adduser maria arquivos
Para remover usurios do grupo, voc usa o comando "deluser", como em:
# deluser joao arquivos
# deluser maria arquivos
Depois de criar o grupo e adicionar os usurios a ele, falta apenas ajustar as permisses
de acesso da pasta, de forma que o grupo tenha acesso completo, como em:
# chgrp arquivos /mnt/arquivos
# chmod 775 /mnt/arquivos
Com isso, trocamos o grupo dono da pasta e dizemos que tanto o dono quanto o grupo
possuem acesso completo. A partir desse ponto, o Samba autoriza o acesso para todos os
usurios cadastrados atravs do smbpasswd e o sistema autoriza a gravao para todos
os usurios que fazem parte do grupo.
Se voc precisar que a alterao seja aplicada de forma recursiva, alterando as
permisses de todas as subpastas e arquivos, adicione a opo "-R" nos dois comandos,
como em:
# chgrp -R arquivos /mnt/arquivos
# chmod -R 775 /mnt/arquivos

Alm de servirem para controlar as permisses de acesso dos usurios s pastas do


sistema, os grupos podem ser usados para ajustar as permisses de acesso do Samba, de
forma bastante simples.
Se voc quer que o compartilhamento fique disponvel apenas para os usurios que
cadastrou no grupo "arquivos", adicione a opo "valid users = +arquivos" na seo
referente ao compartilhamento. O "+" indica que se trata de um grupo e no de um
usurio isolado. O Samba verifica ento quais usurios fazem parte do grupo e autoriza
o acesso. A partir da, quando voc quiser liberar o acesso para um novo usurio, basta
adicion-lo ao grupo:
[arquivos]
path = /mnt/arquivos
writable = yes
valid users = +arquivos
Voc pode tambm especificar uma lista de usurios isolados, separando-os por vrgula,
por espao, ou pelos dois combinados (o que preferir), como em:
[arquivos]
path = /mnt/arquivos
writable = yes
valid users = joao, maria, jose
possvel tambm combinar as duas coisas, indicando um ou mais grupos e tambm
alguns usurios avulsos, como em:
[arquivos]
path = /mnt/arquivos
writable = yes
valid users = +arquivos, jose, joaquim, +admin
Assim como na maioria das opes do Samba, a opo "valid users" exclusiva, ou
seja, ao dizer que os usurios do grupo arquivos devem ter acesso, voc
automaticamente exclui todos os outros. Voc pode tambm fazer o oposto, criando uma
lista de usurios que no devem ter acesso e mantendo o acesso para os demais. Nesse
caso, voc usaria a opo "invalid users", como em:
[arquivos]
path = /mnt/arquivos

writable = yes
invalid users = jose, joaquim
Nesse caso, todos os usurios cadastrados no Samba podem acessar, com exceo dos
usurios jose e joaquim. possvel ainda usar a opo "invalid users" para especificar
excees ao especificar grupos usando a opo "valid users", como em:
[arquivos]
path = /mnt/arquivos
writable = yes
valid users = +arquivos
invalid users = joao
Nesse caso, todos os usurios dentro do grupo arquivos tero acesso, com exceo do
joao. Esta combinao pode ser usada em casos onde o grupo especificado tambm
em outros compartilhamentos e voc precisa bloquear o acesso do usurio a um
compartilhamento especfico, sem remov-lo do grupo.
possvel tambm criar uma lista de escrita, usando a opo "write list". Ela cria uma
camada adicional de proteo, permitindo que, dentro do grupo de usurios com acesso
ao compartilhamento, apenas alguns tenham permisso para alterar os arquivos, como
em:
[arquivos]
path = /mnt/arquivos
writable = no
valid users = +arquivos
write list = maria
Nesse caso, usamos a opo "writable = no", que faz com que o compartilhamento passe
a ser somente-leitura. A seguir, especificamos que os usurios do grupo "arquivos"
devem ter acesso (somente-leitura) e usamos a opo "write list = maria" para criar uma
exceo, dizendo que a maria pode escrever na pasta. importante notar que, neste
exemplo, a maria deve fazer parte do grupo "arquivos", caso contrrio teramos uma
situao interessante, onde ela no consegue alterar os arquivos no compartilhamento,
pois no tem acesso a ele em primeiro lugar. :)
Caso a maria no estivesse cadastrada no grupo, voc deveria incluir o login na opo
"valid users", como em:
[arquivos]

path = /mnt/arquivos
writable = no
valid users = +arquivos, maria
write list = maria
Podemos tambm fazer o oposto, restringindo a escrita para alguns usurios, mas
mantendo o acesso para todos os demais. Nesse caso, usamos a opo "read list" para
criar uma lista de excees, como em:
[arquivos]
path = /mnt/arquivos
writable = yes
valid users = +arquivos, +admin
read list = maria, jose
Nesse exemplo, usamos a opo "writable = yes" e especificamos que os usurios
dentro dos grupos "arquivos" e "admin" tem acesso ao compartilhamento. Em seguida,
usamos a opo "read list" para limitar o acesso dos usurios maria e jose, de forma que
eles possam apenas ler, sem alterar os arquivos dentro da pasta.
Outra opo relacionada a "read only", que tambm aceita os valores "yes" e no". Na
verdade, ela tem a mesma funo da opo "writable", apenas usa uma lgica invertida.
Dizer "writable = yes" ou dizer "read only = no" tem exatamente o mesmo efeito, como
seis e meia-dzia. Em geral, voc usa uma ou outra de acordo com o contexto, como
uma forma de tornar o arquivo mais legvel, como em:
[modelos]
path = /mnt/modelos
read only = yes
Continuando, possvel restringir o acesso tambm com base no endereo IP ou no
nome da mquina a partir da qual o usurio est tentando acessar o compartilhamento.
Isso permite adicionar uma camada extra de segurana no acesso a arquivos
importantes, j que alm do login e senha, verificado a partir de qual mquina o acesso
proveniente.
Isso feito atravs das opes "hosts allow" e "hosts deny" que permitem,
respectivamente, criar uma lista de mquinas que podem e que no podem acessar o
compartilhamento. As listas podem incluir tanto os endereos IP quanto os nomes das
mquinas.

Para restringir o acesso ao compartilhamento a apenas duas mquinas especficas, voc


usaria:
[arquivos]
path = /mnt/arquivos
writable = yes
hosts allow = 192.168.1.23, 192.168.1.24
ou
[arquivos]
path = /mnt/arquivos
writable = yes
hosts allow = sparta, athenas
possvel tambm fazer o inverso, bloqueando o compartilhamento para acessos
provenientes das duas mquinas. Nesse caso, mesmo que o usurio tente acessar usando
um login vlido, vai receber a mensagem de acesso negado, como se o login tivesse sido
bloqueado ou a senha tenha sido alterada. A lista no possui um tamanho mximo, voc
pode incluir quantas mquinas precisar, separando os endereos ou nomes por vrgula e
espao. Voc pode inclusive misturar endereos IP com nomes de mquinas, como nesse
exemplo:
[arquivos]
path = /mnt/arquivos
writable = yes
hosts deny = 192.168.1.23, athenas
possvel ainda combinar a restrio com base nos nomes e endereos com a restrio
com base nos logins de acesso, de forma que o acesso seja autorizado apenas quando as
duas condies forem satisfeitas.
Para permitir que apenas a maria e o joao acessem o compartilhamento e ainda assim
apenas se estiverem usando uma das duas mquinas permitidas, voc usaria:
[arquivos]
path = /home/arquivos
writable = yes

valid users = maria, joao


hosts allow = 192.168.1.23, 192.168.1.24
Voc pode autorizar ou restringir o acesso para uma faixa inteira de endereos omitindo
o ltimo octeto do endereo. Por exemplo, para que apenas clientes dentro da rede
"192.168.1.x" tenham acesso, voc inclui apenas a parte do endereo referente rede,
omitindo o octeto referente ao host, como em:
[arquivos]
path = /mnt/arquivos
writable = yes
hosts allow = 192.168.1.
Se precisar criar excees, limitando o acesso a algumas mquinas dentro da faixa de
endereos especificada, voc pode usar a opo "EXCEPT" para especificar as
excees, como em:
[arquivos]
path = /mnt/arquivos
writable = yes
hosts allow = 192.168.1. EXCEPT 192.168.1.23, 192.168.1.24
Com isso, todos os endereos dentro da faixa teriam acesso, com exceo do .23 e do .
24. O mesmo pode ser feito ao usar a opo "hosts deny", como em:
[restrito]
path = /mnt/sda2/restrito
writable = yes
valid users = isac
hosts deny = 192.168.1. EXCEPT 192.168.1.23
Aqui a lgica invertida e todos os hosts dentro da faixa de endereos so bloqueados,
com exceo do .23, que passa a ser o nico aceito pelo servidor.
Outro parmetro que pode ser usado ao criar excees o "ALL", que inclui todos os
endereos possveis. Se a idia que apenas um determinado endereo possa acessar o
compartilhamento, uma opo usar "hosts deny = ALL EXCEPT 192.168.1.34".

O default do Samba permitir o acesso a partir de qualquer mquina, de forma que se


voc no usar nem a opo "hosts allow", nem a "hosts deny", qualquer mquina poder
acessar o compartilhamento.
Ao usar apenas a opo "hosts allow", apenas as mquinas listadas tero acesso ao
compartilhamento, as demais sero recusadas. Ao usar apenas a opo "hosts deny",
apenas as mquinas listadas no tero acesso ao compartilhamento (as demais
continuam acessando).
Ao combinar o uso das opes "hosts allow" e "hosts deny", a opo "hosts allow" tem
precedncia (no importa a ordem em que elas sejam colocadas), de forma que as
mquinas listadas tero acesso, mesmo que ele seja negado pela opo "hosts deny". Por
exemplo, ao usar:
[isos]
path = /mnt/isos
hosts allow = 192.168.1.
hosts deny = 192.168.1.43
comment = Algo est errado
... o host "192.168.1.43" continuar tendo acesso ao compartilhamento, pois faz parte da
faixa de endereos cujo acesso autorizado pela opo "hosts allow". Neste caso, o
Samba no considera a opo "hosts deny = 192.168.1.43" como uma exceo, mas sim
como um erro de configurao. Para bloquear a mquina, voc deveria usar:
[isos]
path = /mnt/isos
hosts allow = 192.168.1. EXCEPT 192.168.1.43
comment = Agora sim
Em situaes onde voc precisa restringir temporariamente o acesso a um determinado
compartilhamento (para alguma tarefa de manuteno, por exemplo) voc pode usar a
opo "available = no", como em:
[arquivos]
path = /home/arquivos
writable = yes
valid users = maria, joao
available = no

Ela faz com que o compartilhamento "desaparea", da mesma forma que se voc
apagasse ou comentasse a configurao. A principal vantagem que ao apagar voc
precisaria escrever tudo de novo para reativar o compartilhamento, enquanto ao usar o
"available = no" voc precisa apenas remover a opo ou mudar para "available = yes".
Outra opo interessante que pode ser includa a "browseable = no", que transforma o
compartilhamento em um compartilhamento oculto:
[arquivos]
path = /home/arquivos
writable = yes
browseable = no
Com isso, ele no aparece mais no ambiente de redes, mas pode ser acessado
normalmente se voc especificar o nome manualmente ao mapear o compartilhamento:

Essa no propriamente uma opo de segurana, mas pode ser usada para afastar os
curiosos dos compartilhamentos com acesso restrito.
Concluindo, muitas opes que ficam disponveis no Swat podem ser omitidas ao
configurar manualmente, simplesmente porque so o default no Samba. O prprio Swat

evita incluir opes redundantes ao gerar o arquivo, incluindo apenas as configuraes


que so diferentes dos valores default.
No necessrio incluir opes como "writable =no", "available = yes" ou "browseable
= yes" no arquivo, pois estes j so os valores usados por padro no Samba. Apesar
disso, us-los tambm no atrapalha em nada, de forma que nada impede que voc os
inclua no arquivo para se lembrar mais facilmente das opes.
Outra dica que voc pode verificar a qualquer momento quais usurios e quais
mquinas esto acessando compartilhamentos no servidor usando o comando
"smbstatus, como em:"
# smbstatus
Samba version 3.0.24
PID Username Group Machine
------------------------------------------------------------------17107 gdh gdh hp (192.168.1.2)
11588 gdh gdh semprao (192.168.1.10)
Service pid machine Connected at
------------------------------------------------------IPC$ 17107 hp Sun Oct 28 15:54:04 2007
arquivos 11588 semprao Sun Oct 28 15:23:59 2007
No locked files
Neste exemplo, podemos ver que o usurio "gdh" est logado no servidor a partir de
duas mquinas diferentes, um indcio de que duas pessoas esto utilizando a mesma
conta.

A seo [global]
Samba, parte 2: Configurao avanada do Samba (atualizado)
Carlos E. Morimoto
24/06/2009
Todas as opes colocadas dentro da seo referente ao compartilhamento
valem apenas para ele, o que permite que voc crie diversos compartilhamentos
diferentes e use um conjunto prprio de permisses para cada um. Estas mesmas
opes, junto com um conjunto adicional podem ser especificadas de forma geral dentro
da seo [global] do smb.conf.

Nos exemplos anteriores, especificamos apenas o nome do servidor e o grupo de


trabalho na seo [global]. Isto suficiente para o servidor participar da rede e
compartilhar arquivos, mas, naturalmente, existem muitas outras opes que podem ser
usadas.
Em primeiro lugar, temos o nvel de segurana do servidor, definido atravs da opo
"security". O default no Samba 3 usar o controle de acesso baseado em usurio, que
o mesmo modo de acesso usado pelas verses domsticas do Windows 2000, XP e
Vista. Neste modo, voc cadastra os logins e senhas no servidor, define as permisses de
acesso e o servidor checa as credenciais dos clientes antes de autorizar o acesso, a
configurao que vimos at aqui. Este modo ativado adicionando a opo "security =
user" na seo [global], mas no necessrio us-la no Samba 3, pois, como disse, ela
usada por padro:
security = user
Em seguida, temos o modo "security = domain". Ao contrrio do que o nome pode
sugerir primeira vista, este modo no destinado a fazer com que o Samba atue como
um controlador de domnio. Pelo contrrio, ao configurar um servidor Samba como
PDC, voc continua usando a opo "security = user", da mesma forma que faria ao
usar um servidor em modo stand alone. A opo "security = domain" usada quando
voc quer que um servidor Samba participe do domnio como cliente, autenticando-se
em um servidor PDC j existente (que pode tanto ser outro servidor Samba, quanto ser
um servidor Windows).
Existem ainda os modos "security = share" e "security = server", que imitam o sistema
de acesso utilizado por estaes Windows 95/98. Estes dois modos so obsoletos e
devem ser removidos em futuras verses do Samba. Antigamente, o modo "security =
share" era usado em casos onde voc queria disponibilizar compartilhamentos pblicos
na rede, sem muita segurana, mas hoje em dia isso pode ser feito usando a conta guest
(como veremos em detalhes mais adiante). O modo "security = server" descende da
poca em que o Samba ainda no era capaz de atuar como PDC; este modo permitia que
ele atuasse como um proxy de autenticao, repassando as requisies para o servidor
de autenticao principal. Atualmente este modo no mais usado.
Outra opo usada por padro no Samba 3 a "encrypt passwords = yes", de forma
que tambm no necessrio especific-la manualmente no arquivo. Entretanto,
saudvel inclu-la em modelos e exemplos de configurao pois pode acontecer de
algum tentar usar o modelo no Samba 2, onde o default era que ela ficasse desativada.
encrypt passwords = yes
muito comum que seja includa tambm a opo "invalid users = root", uma medida
de segurana para evitar que a conta de root seja usada ao acessar o servidor. A lgica
que a conta de root a nica conta presente em qualquer sistema Linux, de forma que
algum que decidisse usar um ataque de fora bruta para tentar obter acesso ao servidor,
testando todas as senhas possveis, comearia justamente pela conta de root.

Entretanto, a conta de root necessria para dar upload de drivers de impresso e para
logar os clientes ao usar o servidor Samba como PDC, situaes onde a linha "invalid
users = root" deve ser comentada ou removida.
Continuando, as opes definidas dentro da seo [global] valem para todos os
compartilhamentos do servidor, diferente das opes colocadas dentro da seo
referente a cada um. Por exemplo, ao usar:
[global]
netbios name = Servidor
workgroup = Grupo
hosts allow = 192.168.1.
... apenas as mquinas dentro da faixa de endereos especificadas tero acesso ao
servidor, o que seria interessante do ponto de vista da segurana, j que de qualquer
forma o servidor deve ser acessado apenas por clientes da rede local.
O maior problema que a opo "hosts allow" usada na seo [global] tem precedncia
sobre qualquer opo "hosts deny" usada dentro dos compartilhamentos, o que pode
criar problemas caso voc queira restringir o acesso de alguma mquina da rede local a
um determinado compartilhamento.
Por exemplo, ao usar:
[global]
netbios name = Servidor
workgroup = Grupo
hosts allow = 192.168.1.
[share]
path = /mnt/sda2/shared
hosts deny = 192.168.1.2
... a mquina "192.168.1.2" continuaria tendo acesso ao compartilhamento [share], pois
o acesso autorizado pela opo "hosts allow = 192.168.1." usada na seo [global].
Nesse caso, o melhor seria remover a linha "hosts allow = 192.168.1." da seo [global]
e deixar apenas a opo "hosts deny = 192.168.1.2" na seo [share]:
[global]
netbios name = Servidor

workgroup = Grupo
[share]
path = /mnt/sda2/shared
hosts deny = 192.168.1.2
Em caso de conflito direto entre uma regra definida na seo [global] e outra definida
em um dos compartilhamentos, a regra definida na seo [global] tem precedncia. Por
exemplo, ao usar:
[global]
netbios name = Servidor
workgroup = Grupo
hosts deny = 192.168.1.3
[share]
path = /mnt/sda2/shared
hosts allow = 192.168.1.3
... a mquina "192.168.1.3" continuar sem acesso ao compartilhamento "share" (ou a
qualquer outro recurso do servidor), j que vale a regra definida na seo [global].
Enquanto a linha "hosts deny = 192.168.1.3" no for removida, a mquina no ter
acesso a nenhum dos compartilhamentos, no importa o que digam as demais linhas do
arquivo.
Continuando, um problema comum enfrentado ao administrar uma rede mista so os
usurios escreverem a primeira letra do login em maisculo, como em "Joao" no lugar
de "joao". No Windows isso no um problema, j que o sistema case insensitive,
mas no Linux faz com que o sistema recuse o login. Uma forma de evitar isso no Samba
usar a opo "username level", como em:
username level = 2
Esta opo faz com que o Samba verifique vrias combinaes de maisculas e
minsculas caso o login seja recusado pelo sistema. O nmero indica o volume de
variaes, que pode ser qualquer nmero inteiro. Ao usar o valor "2", o Samba verifica
at dois nveis, incluindo variaes como JOao, jOAo, Joao, jOaO e assim por diante.
Usar um nmero maior pode retardar a autenticao, j que o Samba precisar testar
muitas combinaes, por isso so geralmente usados os valores "1" ou "2".
Outra peculiaridade digna de nota a questo dos nomes de arquivos. No Windows, os
nomes de arquivos so salvos da forma como digitados pelo usurio, preservando os
caracteres maisculos e minsculos. Entretanto, o sistema case insensitive, de forma

que o sistema no diferencia um arquivo chamado "Trabalho.txt" de outro chamado


"trabalho.txt".
Embora o Linux seja case sensitive, o Samba tenta emular o comportamento de uma
mquina Windows ao localizar arquivos. Se o cliente pede o arquivo "Trabalho.txt",
quando na verdade o arquivo armazenado na pasta se chama "trabaLho.txt" o Samba vai
acabar fornecendo o arquivo correto para o cliente, pois o encontrar depois de testar
diversas combinaes de maisculas e minsculas.
No Samba 3 este recurso funciona muito bem, mas tem a desvantagem de consumir uma
certa quantidade de memria do servidor. Em um pequeno servidor de rede local, isso
no faz diferena, mas em um servidor que atende um grande nmero de requisies, a
diferena pode se tornar considervel.
Voc pode simplificar as coisas orientando o Samba a salvar todos os arquivos em
minsculas. Para isso, adicione as linhas:
preserve case = no
default case = lower
No caso de servidores com duas ou mais interfaces de rede, sobretudo no caso de
servidores conectados simultaneamente internet e rede local, voc pode especificar
qual interface ser usada pelo Samba atravs da opo "interfaces", que deve ser
combinada com a opo "bind interfaces only = yes". Para que o servidor escute apenas
a interface eth0, ignorando tentativas de conexo em outras interfaces, voc usaria:
interfaces = eth0
bind interfaces only = yes
Por default, o Samba escuta em todas as interfaces, o que (se no houver nenhum
firewall ativo) pode expor seus compartilhamentos para a Internet caso voc ative o
Samba em uma mquina conectada diretamente internet, como no caso de um servidor
que compartilha a conexo. recomendvel usar sempre estas duas opes, como uma
forma de garantir que o Samba ficar disponvel apenas na interface desejada.
Outra opo interessante a "netbios aliases", que permite criar "apelidos" para o
servidor, de modo de que ele possa ser acessado por mais de um nome. Usando um
alias, o servidor realmente aparece duas ou mais vezes no ambiente de rede, como se
existissem vrias mquinas. Geralmente, isso acaba confundindo mais do que ajudando,
mas pode ser til em algumas situaes, quando, por exemplo, um servidor desativado
e os compartilhamentos so movidos para outro. O novo servidor pode responder pelo
nome do servidor antigo, permitindo que os desavisados continuem acessando os
compartilhamentos atravs do endereo anterior. Para us-la, basta adicionar a opo,
seguida pelos apelidos desejados, como em:
[global]
netbios name = Servidor

netbios aliases = athenas, sparta


workgroup = Grupo
No tpico sobre o Swat falei sobre as opes "Local Master", "OS Level" e "Preferred
Master", que definem se o servidor Samba deve participar das eleies para Master
Browser e com qual nvel de credencial. Para que o servidor participe com OS Level
100, voc adicionaria as linhas:
local master = yes
os level = 100
preferred master = yes
Um segundo servidor Samba na rede poderia participar com uma credencial mais baixa,
de forma a assumir o cargo apenas caso o servidor principal esteja desconectado da
rede. Para isso, basta usar um valor mais baixo na opo OS Level, como em:
local master = yes
os level = 90
preferred master = no
O valor da opo OS Level absoluto, no se trata de um sorteio. Um servidor
configurado com o valor "100" ganha sempre de um com o valor "99", por exemplo.
Se voc omitir as trs linhas, o servidor simplesmente utiliza os valores default (local
master = yes, os level = 20), que fazem com que ele participe das eleies, mas utilize
credenciais baixas.
A opo "wins support = yes" faz com que o servidor Samba passe a trabalhar como
um servidor WINS (Windows Internetworking Name Server) na rede. O WINS um
protocolo auxiliar dentro das redes Microsoft, responsvel pela navegao na rede e
listagem dos compartilhamentos e outros recursos disponveis, de forma similar a um
servidor DNS.
O uso do WINS no obrigatrio; sua rede vai muito provavelmente funcionar muito
bem sem ele. Entretanto, sem um servidor WINS os clientes passam a usar pacotes de
broadcast para a navegao (a menos que voc utilize um domnio), o que aumenta o
trfego da rede e torna todo o processo mais passvel de falhas.
Outra limitao importante que os pacotes de broadcast so descartados pelos
roteadores, o que faz com que eles (os pacotes de broadcast) no sejam transmitidos de
um segmento a outro da rede caso ela esteja dividida em vrios segmentos, interligados
atravs de roteadores. O mesmo acontece caso voc tenha duas redes ligadas atravs de
uma VPN, onde o trfego seja roteado. Em ambos os casos, os pacotes de broadcast so
descartados pelos roteadores, fazendo com que os micros em um segmento no
enxerguem os micros do outro e vice-versa.

A soluo em ambos os casos implantar um servidor WINS na rede. Com isso, os


clientes passam a consultar o servidor ao invs de mandar pacotes de broadcast, fazendo
com que a navegao funcione mesmo ao utilizar vrios segmentos de rede. Para isso,
basta incluir a opo dentro da seo [global] do smb.conf:
wins support = yes
O prximo passo configurar os clientes da rede para utilizarem o servidor. A opo
fica escondida nas propriedades da conexo de rede, no Protocolo TCP/IP >
Propriedades > Avanado > WINS, onde voc deve adicionar o endereo IP do servidor:

A configurao do servidor WINS pode ser tambm enviada automaticamente para os


clientes. Para isso, necessrio incluir a opo "netbios-name-servers" na configurao
do servidor DHCP (no arquivo "/etc/dhcp3/dhcpd.conf", ou "/etc/dhcpd.conf"),
especificando o nome do servidor, como em:
option netbios-name-servers 192.168.1.254;
Esta linha colocada dentro da seo com a configurao da rede, como nesse exemplo:
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.100 192.168.1.199;
option routers 192.168.1.1;
option domain-name-servers 192.168.1.1;
option netbios-name-servers 192.168.1.254;
option broadcast-address 192.168.1.255;
}
No caso de outros micros Linux rodando o Samba que forem ser configurados como
clientes do servidor principal, a configurao feita adicionando a opo "wins server =
servidor" (tambm na seo [global] do smb.conf), onde voc especifica o endereo IP
do servidor principal, como em:
wins server = 192.168.1.254
Uma observao importante que as opes "wins support" e "wins server" so
mutuamente exclusivas. Ou a mquina atua como servidor WINS, ou como cliente
(nunca as duas coisas ao mesmo tempo), de forma que voc no deve jamais combinar
as duas opes dentro da configurao.
Em verses antigas do Samba, combinar as duas opes na configurao simplesmente
fazia com que o servidor deixasse de funcionar. Nas atuais o resultado no chega a ser
dramtico (o servidor vai simplesmente ignorar a opo que for colocada depois), mas
mesmo assim este um erro grave de configurao que deve ser evitado.
Um exemplo de seo [global] usando as opes que vimos at aqui seria:
[global]
netbios name = Athenas
server string = Servidor Samba
workgroup = Grupo

username level = 1
preserve case = no
default case = lower
interfaces = eth0
bind interfaces only = yes
local master = yes
os level = 100
preferred master = yes
wins support = yes
Esta configurao ativa o teste de variaes de maisculas e minsculas para os logins
recusados (apenas um nvel), faz com que todos os arquivos salvos nos
compartilhamentos sejam renomeados para caracteres minsculos, faz com que o
servidor escute apenas a interface eth0, que seja master browser da rede e que atue
como servidor WINS. Este um arquivo de configurao perfeitamente utilizvel,
faltaria apenas adicionar as sees referentes aos compartilhamentos.

A seo [homes]
Samba, parte 2: Configurao avanada do Samba (atualizado)
Carlos E. Morimoto
24/06/2009
Uma vantagem de utilizar usurios "reais" no servidor Samba, em vez de
usurios castrados, que voc tem a opo de compartilhar os diretrios home atravs
da seo [homes] no smb.conf. Este um servio interno do Samba, que permite
compartilhar automaticamente o diretrio home de cada usurio, sem precisar criar um
compartilhamento separado para cada um.
A configurao mais comum compartilhar os diretrios home com permisso de
acesso apenas para o respectivo usurio. Dessa forma, cada usurio tem acesso apenas
ao seu prprio diretrio home (que aparece no ambiente de redes como um
compartilhamento com o mesmo nome), sem poder acessar, nem muito menos alterar o
contedo dos diretrios home dos demais usurios. Nesse caso, a configurao fica:
[homes]
valid users = %S
read only = no

create mask = 0700


directory mask = 0700
browseable = no
No necessrio especificar a pasta a compartilhar, pois ao omitir a linha "path" o
Samba sabe que deve compartilhar o home de cada usurio. As opes "create mask =
0700" e "directory mask = 0700" fazem com que todos os arquivos e pastas criados pelo
usurio dentro do home sejam acessveis apenas por ele mesmo. A opo "browseable =
no" faz com que cada usurio possa ver apenas seu prprio diretrio, o que reforado
pela opo "valid users = %S", que diz explicitamente que apenas o prprio usurio
deve ter acesso sua pasta home.
Uma queixa comum que ao acessar o diretrio home atravs do Samba, os usurios
vero todos os arquivos e pastas de configurao de programas que so salvos dentro do
diretrio home, o que pode ser confuso.
Uma forma de evitar isso alterar a configurao, de forma que o Samba compartilhe
uma pasta vazia dentro do home, e no o diretrio home em si. Com isso mantido o
propsito de oferecer uma pasta particular para o usurio, onde ele possa salvar seus
arquivos particulares e seus backups, sem a poluio gerada pela presena dos arquivos
de configurao. A configurao nesse caso ficaria:
[homes]
path = /home/%u/share
valid users = %S
read only = no
create mask = 0700
directory mask = 0700
browseable = no
A linha "path = /home/%u/share" especifica que o Samba deve agora compartilhar a
pasta "share" dentro do home e no mais o diretrio home em si (voc pode especificar
outra pasta qualquer) e a linha "valid users = %S" garante que a pasta ficar acessvel
apenas para o prprio usurio.
Naturalmente, a pasta "share" precisa ser criada dentro do home de cada usurio
manualmente. Voc pode fazer isso de forma automtica para todos os usurios usando
este mini shell script:
cd /home
for i in *; do

mkdir $i/share
chown $i:$i $i/share
done
Aproveite para criar tambm a pasta "share" dentro do diretrio "/etc/skel", que usado
como um modelo para a criao do home de novos usurios. Isso faz com que o
diretrio seja adicionado ao home de todos os usurios criados da em diante, de forma
automtica:
# mkdir /etc/skel/share
Concluindo, aqui vai uma lista de outras variveis do Samba para referncia:
%a : A verso do Windows usada, onde o "%a" substitudo pelas strings "Win95"
(Windows 95/98), "WinNT" (Windows NT 3.x ou 4.x), "Win2K" (Windows 2000 ou
XP) ou "Samba" (mquinas Linux rodando o Samba)
%I : Endereo IP da mquina cliente (ex: 192.168.1.2)
%m : Nome da mquina cliente (ex: cliente1)
%L : Nome do servidor (ex: athenas)
%u : Nome do usurio, como cadastrado no servidor Linux (ex: joao)
%U : Nome do usurio, como enviado pelo cliente Windows (pode ser diferente do
login cadastrado no servidor em algumas situaes)
%H : Diretrio home do usurio (ex: /home/maria)
%g : Grupo primrio do usurio (ex: users)
%S : Nome do compartilhamento atual (o valor informado entre colchetes, ex:
arquivos)
%P : Pasta compartilhada (o valor informado na opo "path", ex: /mnt/arquivos)
%v : Verso do Samba (ex: 3.2.24)
%T : Data e horrio atual
Ao longo do texto, veremos alguns outros exemplos de uso destas variveis, mas voc
pode us-las em outras situaes para criar compartilhamentos "inteligentes", que
mostram pastas diferentes de acordo com as propriedades do cliente. Por exemplo, a
varivel "%a" (que indica a verso do Windows no cliente), poderia ser usada para criar
um compartilhamento com drivers, que mostrasse diretamente a pasta com os drivers
corretos para a verso do Windows usada. Nesse caso, voc poderia usar algo como:

[drivers]
path = /mnt/sda2/drivers/%a
read only = yes
A pasta "/mnt/sda2/drivers/" incluiria uma srie de sub-pastas, com os valores possveis
para a varivel, incluindo "Win95", "WinNT", "Win2K" e "Samba". Ao acessar o
compartilhamento, o cliente v apenas o contedo da pasta correspondente ao sistema
operacional usado.

A conta guest
Samba, parte 2: Configurao avanada do Samba (atualizado)
Carlos E. Morimoto
24/06/2009
No Windows XP usado por padro um modo simplificado de
compartilhamento de arquivos, o "simple sharing", que visa imitar o modo de acesso do
Windows 95/98, onde os compartilhamentos so pblicos e voc apenas define se eles
so apenas leitura ou leitura e escrita.
Na verdade, o Windows XP usa o controle de acesso com base no usurio, assim como
o Samba 3, mas, por baixo dos panos, todos os acessos passam a ser mapeados para a
conta "guest" (ativa por padro), o que permite que usurios remotos sem login vlido
acessem os compartilhamentos diretamente. Este recurso tambm chamado de "force
guest".
Naturalmente, podemos fazer o mesmo no Samba. Para isso, adicione as linhas abaixo
dentro da seo [global] do smb.conf:
map to guest = bad user
guest account = guest
A primeira opo faz com que sempre que um cliente especificar um usurio invlido ao
tentar acessar o servidor, o servidor mapeie a requisio para o login especificado na
opo "guest account", que usada para acessar o compartilhamento. Neste exemplo,
qualquer usurio no autenticado passaria a usar a conta "guest", que deve ter sido
previamente cadastrada no servidor. Voc pode tambm usar qualquer outra conta
vlida, como em "guest account = maria".
Uma opo menos usada a "map to guest = bad password". Ela se diferencia da
"map to guest = bad user" pois permite o acesso apenas caso o usurio especifique um
login vlido, mas erre apenas a senha. O principal motivo dela no ser muito usada
que ela confunde o usurio, j que ele ou vai achar que est realmente logado no
servidor (quando na verdade est apenas acessando de forma limitada atravs da conta
guest) ou vai passar a achar que o servidor aceita qualquer senha.

Para que os usurios no-autenticados possam acessar os compartilhamentos, voc deve


explicitamente autorizar o acesso, adicionando a opo "guest ok = yes" na
configurao, como em:
[global]
netbios name = Sparta
workgroup = Grupo
map to guest = bad user
guest account = guest
[publico]
path = /mnt/sda2/publico
writable = yes
guest ok = yes
Note que no exemplo usei a opo "writable = yes". Entretanto, para que os usurios
no-autenticados possam efetivamente escrever na pasta, necessrio verificar se as
permisses de acesso da pasta permitem que a conta especificada ("guest" no exemplo)
altere os arquivos. Como disse anteriormente, o Samba est subordinado s permisses
de acesso do sistema.
Outra opo comum em compartilhamentos pblicos a "guest only = yes" (usada no
lugar da "guest ok = yes", na seo [global]). Ela simula o "simple sharing" do Windows
XP, mapeando qualquer acesso para a conta guest, sem sequer abrir o prompt de login
para o cliente.
Vamos ento a mais um exemplo de configurao do smb.conf, desta vez usando a conta
guest para criar um servidor de arquivos pblico. Ele possui duas parties de arquivos
(montadas nas pastas "/mnt/hda2 e "/mnt/sda1") que ficam disponveis a todos os
usurios da rede:
[global]
netbios name = Plutus
server string = Servidor pblico
workgroup = Grupo
local master = yes
os level = 100

preferred master = yes


wins support = yes
map to guest = bad user
guest account = gdh
[arquivos]
path = /mnt/hda2
writable = yes
guest ok = yes
[backups]
path = /mnt/sda1
writable = yes
guest ok = yes
Esta configurao bastante simples e a prova de falhas. O servidor vai assumir a
funo de master browser, se responsabilizando pela navegao dos clientes e vai
mapear qualquer acesso para a conta "gdh" usada na opo "guest account", permitindo
que qualquer um possa ler e gravar arquivos nos dois compartilhamentos.
As duas principais observaes so que o usurio "gdh" deve ser um usurio real do
sistema, cadastrado no servidor Samba, e que ele deve ser o dono das duas pastas
compartilhadas, de forma que no tenha problemas para acessar seu contedo. Isso pode
ser feito usando os 4 comandos a seguir:
# adduser gdh
<senha>
# smbpasswd -a gdh
<mesma senha>
# chown -R gdh:gdh /mnt/hda2
# chown -R gdh:gdh /mnt/sda1
Essa configurao ideal para pequenos servidores de rede local, que devem apenas
disponibilizar arquivos na rede, sem muita segurana. Ela similar ao exemplo de
configurao para um servidor de arquivos pblico que inclu no livro Redes, Guia
Prtico.

Lixeira no Samba
Samba, parte 2: Configurao avanada do Samba (atualizado)
Carlos E. Morimoto
24/06/2009
Em qualquer servidor de arquivos, a principal prioridade assegurar a
integridade e a segurana dos dados. Entretanto, por mais estvel que seja a rede e por
mais robusto que seja o servidor, o elo mais fraco da cadeia acaba sendo sempre o
usurio. De nada adianta um servidor perfeitamente estvel se ele deleta um arquivo
importante sem querer.
Pensando nisso, o Samba oferece a opo de usar uma lixeira, que pode lhe poupar
muita dor de cabea em diversas situaes. Isso feito atravs da opo "vfs object =
recycle", que cria uma lixeira dentro de cada pasta compartilhada, que passa a
armazenar todos os arquivos deletados. Isso previne a remoo acidental de arquivos, j
que o usurio passa a precisar deletar o arquivo e em seguida limpar o contedo da
lixeira para realmente remov-lo, o que o comportamento esperado por muitos.
Por padro, os arquivos deletados vo para a pasta ".recycle" (dentro do
compartilhamento), mas o nome pode ser alterado atravs da opo "recycle:repository
= lixeira" (onde o "lixeira" o nome desejado, que pode ser qualquer um). Quando uma
pasta deletada, o padro simplesmente misturar todos os arquivos no diretrio raiz
da lixeira, mas isso pode ser evitado adicionando a opo "recycle:keeptree = yes". Aqui
temos mais um exemplo de compartilhamento, incluindo as trs opes:
[projetos]
path = /mnt/sda2/projetos
writable = yes
valid users = +apolo, isac
vfs object = recycle
recycle:repository = lixeira
recycle:keeptree = yes
Outra opo til a "recycle:versions", que faz com que a lixeira mantenha diferentes
verses do mesmo arquivo, em vez de manter apenas a ltima verso. Os arquivos
repetidos passam ento a ser renomeados para "Copy #1 of Samba.sxw", "Copy #2 of
Samba.sxw" e assim por diante.
recycle:versions = yes
Com isso, voc passa a dormir um pouco mais tranquilo a noite e se salva (na maior
parte dos casos) de precisar recuperar arquivos acidentalmente deletados a partir de

backups. preciso apenas se lembrar de verificar o contedo das lixeiras de vez em


quando e limpar as pastas quando elas comearem a consumir muito espao em disco.
Voc pode inclusive deletar a pasta da lixeira inteira, pois ela recriada
automaticamente quando o prximo arquivo for deletado.

Uma opo para reduzir o problema do espao desperdiado centralizar todas as


lixeiras em uma nica pasta. Isso permite inclusive que voc utilize uma partio ou um
HD separado para armazenar os arquivos da lixeira, sem correr o risco de ela crescer at
ocupar todo o espao disponvel na partio principal. Para isso, usamos a opo
"recycle:repository", seguida da pasta a ser utilizada (que deve ser criada previamente),
como em:
recycle:repository = /var/samba/trash/
Como adicionamos o caminho completo (em vez de usar "recycle:repository = lixeira",
como no exemplo anterior), a opo pode tanto ser adicionada individualmente em cada
compartilhamento quanto ser especificada apenas uma vez na seo [global], o que faz
com que a lixeira passe a ser automaticamente usada para arquivos deletados em todos
os compartilhamentos do servidor.
Centralizar todos os arquivos em uma nica pasta criaria uma grande confuso, j que
ela misturaria arquivos deletados por todos os usurios. Uma soluo adicionar a
varivel "%U", que faz com que os arquivos sejam organizados em vrias subpastas,
separados por usurio (as subpastas usadas por cada usurio so criadas
automaticamente conforme necessrio). Nesse caso a opo fica:

recycle:repository = /var/samba/trash/%U
O problema em usar essa opo que os usurios deixam de ver a lixeira, j que ela
passa a ficar em uma pasta separada. Uma soluo para o problema criar um novo
compartilhamento, que permite que cada usurio veja sua lixeira particular. Para isso,
iremos novamente usar a varivel "%U":
[lixeira]
path = /var/samba/trash/%U
writable = yes
Usei a opo "writable = yes" para permitir que o prprio usurio possa limpar a lixeira
quando quiser, mas isso opcional. Vale lembrar que para que o usurio consiga limpar
os arquivos da lixeira, necessrio que ele tenha permisso de escrita para a pasta
"/var/samba/trash/". Nesse caso, voc tem a opo de simplesmente abrir as permisses
da pasta (chmod 777), ou ajustar manualmente as permisses da sub-pasta de cada
usurio, como em:
# chown -R joao:joao /var/samba/trash/joao
Mais uma medida til para evitar desperdcio de espao bloquear a gravao de
arquivos de backup e de arquivos temporrios na lixeira, j que eles costumam ser
numerosos e raramente so importantes. saudvel bloquear tambm arquivos .iso (que
so tipicamente muito grandes), de forma que eles sejam tambm deletados diretamente.
As extenses de arquivos so especificadas atravs da opo "recycle:exclude" e nomes
de pasta atravs da opo "recycle:exclude_dir", como em:
recycle:exclude = *.tmp, *.log, *.obj, ~*.*, *.bak, *.iso
recycle:exclude_dir = tmp, cache
Assim como a "recycle:repository", as demais opes da lixeira podem tanto serem
especificadas individualmente dentro de cada compartilhamento quanto diretamente
dentro da seo [global], o que naturalmente o mais simples caso voc deseje ativ-la
para todos os compartilhamentos. O default do Samba 3 manter todas as opes
desativadas, de forma que a lixeira s usada quando as opes so especificadas.
Um exemplo de configurao, com a lixeira ativa dentro da seo [global], dois
compartilhamentos de arquivos e mais o compartilhamento que d acesso pasta central
da lixeira por parte dos usurios seria:
[global]
netbios name = Phanteon
server string = Servidor com lixeira
workgroup = Grupo

local master = yes


os level = 100
preferred master = yes
wins support = yes
vfs objects = recycle
recycle:keeptree = yes
recycle:versions = yes
recycle:repository = /var/samba/trash/%U
recycle:exclude = *.tmp, *.log, *.obj, ~*.*, *.bak, *.iso
recycle:exclude_dir = tmp, cache
[engenharia]
path = /mnt/sda2/engenharia
writable = yes
valid users = +engenheiros
[gerencia]
path = /mnt/gerencia
writable = yes
valid users = paulo, rebeca
hosts allow = micro3, micro4
browseable = no
[lixeira]
path = /var/samba/trash/%U
writable = yes

Pgina 06 de 08

Auditando os acessos
Samba, parte 2: Configurao avanada do Samba (atualizado)
Carlos E. Morimoto
24/06/2009
O Samba oferece tambm um recurso de gerao de log. Ele pode ser ativado
adicionando as opes abaixo na seo [global] do smb.conf:
log level = 1
log file = /var/log/samba.log
max log size = 1000
A opo "log level" indica o nvel das mensagens (de 0 a 10), sendo que o nvel 0
mostra apenas mensagens crticas, o nvel 1 mostra alguns detalhes sobre os acessos e
os demais mostram diversos nveis de informaes de debug, teis a desenvolvedores. A
opo "log file" indica o arquivo onde ele ser gerado e a "max log size" indica o
tamanho mximo, em kbytes.
A partir do Samba 3.04 foi includo um mdulo de auditoria, que permite logar os
acessos e as modificaes feitas de uma forma muito mais completa que o log
tradicional. Isso feito atravs do mdulo "full_audit", que (do ponto de vista tcnico)
funciona de forma similar ao mdulo "recycle" usado pela lixeira.
O primeiro passo ativar o mdulo, o que feito atravs da linha abaixo:
vfs objects = full_audit
O prximo passo definir quais operaes devem ser logadas atravs da opo
"full_audit:success", como em:
full_audit:success = open, opendir, write, unlink, rename, mkdir, rmdir, chmod, chown
(as opes formam uma nica linha)
As opes que inclu no exemplo so open (ler um arquivo), opendir (ver os arquivos
dentro de uma pasta), write (alterar um arquivo), unlink (deletar um arquivo), rename
(renomear um arquivo), mkdir (criar um diretrio), rmdir (remover um diretrio),
chmod (alterar as permisses de acesso de um arquivo) e chown (mudar o dono de um
arquivo).
Voc pode remover algumas destas opes, deixando apenas as opes desejadas, ou ver
uma lista completa das opes que podem ser includas no manual do vfs_full_audit,
disponvel no:
http://samba.org/samba/docs/man/manpages-3/vfs_full_audit.8.html

Continuando a configurao, especificamos as informaes que desejamos que sejam


includas no log, usando a opo "full_audit:prefix". Aqui podemos utilizar as variveis
que mostrei no tpico sobre o compartilhamento [homes], como a "%u" (o nome do
usurio), "%I" (o IP da mquina) e "%S" (o nome do compartilhamento onde foi feito o
acesso ou a alterao). No necessrio incluir a varivel referente ao nome da
mquina, pois o nome includo automaticamente:
full_audit:prefix = %u|%I|%S
Por padro, o mdulo loga no apenas os acessos e modificaes, mas tambm um
grande volume de mensagens de alerta e erros gerados durante a operao. A opo
"full_audit:failure = none" evita que estas mensagens sejam logadas, fazendo com que o
log fique muito mais limpo e seja mais fcil encontrar as opes que realmente
interessam:
full_audit:failure = none
Concluindo, especificamos o nvel dos alertas, entre os suportados pelo syslog, como
em:
full_audit:facility = local5
full_audit:priority = notice
Juntando tudo, temos:
vfs objects = full_audit
full_audit:success = open, opendir, write, unlink, rename, mkdir, rmdir, chmod, chown
full_audit:prefix = %u|%I|%S
full_audit:failure = none
full_audit:facility = local5
full_audit:priority = notice
Esta configurao pode ser tanto includa dentro da seo [global] (de forma que o log
inclua os acessos e as alteraes feitas em todos os compartilhamentos) quanto ser
includa apenas na configurao de um compartilhamento especfico.
Com isso, o Samba vai passar a gerar os eventos referentes aos acessos. Falta agora
configurar o sysklogd (o servio responsvel pela gerao dos logs do sistema), para
logar os eventos, gerando o arquivo de log que poder ser consultado. Para isso, abra o
arquivo "/etc/syslog.conf" e adicione a linha abaixo:
local5.notice /var/log/samba-full_audit.log

Note que o "local5.notice" corresponde aos valores informados nas opes


"full_audit:facility" e "full_audit:priority", enquanto o "/var/log/samba-full_audit.log"
o arquivo de log que ser gerado.
Depois de concluda a configurao, reinicie os servios e o log passar a ser gerado
imediatamente:
# /etc/init.d/samba restart
# /etc/init.d/sysklogd restart
Dentro do arquivo, voc ver entradas contendo a data e hora, o nome da mquina, o
usurio, o IP da mquina, o nome do compartilhamento, a operao realizada e o nome
do arquivo ou pasta onde ela foi realizada, como em:
Nov 18 15:21:15 m5 smbd_audit: joao|192.168.1.23|arquivos|opendir|ok|. Nov 18
15:21:29 m5 smbd_audit: joao|192.168.1.23|arquivos|open|ok|r|addr.txt Nov 18
15:21:34 m5 smbd_audit: joao|192.168.1.23|arquivos|mkdir|ok|trabalho Nov 18
15:21:36 m5 smbd_audit: joao|192.168.1.23|arquivos|opendir|ok|trabalho Nov 18
15:21:43 m5 smbd_audit: joao|192.168.1.23|arquivos|open|ok|w|trabalho/Samba.sxw
Nov 18 15:21:44 m5 smbd_audit: joao|192.168.1.23|arquivos|open|ok|w|
trabalho/foto.jpg
O log conter entradas referentes a todos os usurios e mquinas, mas fcil ver apenas
as entradas referentes a um determinado usurio, compartilhamento, endereo IP ou
outro parmetro qualquer ao listar o arquivo pelo terminal usando o grep, que permite
mostrar apenas as linhas contendo determinados trechos de texto, como em:
# cat /var/log/samba-full_audit.log | grep "joao|192.168.1.23"
(mostra os acessos provenientes do usurio joao, feitos a partir do endereo
192.168.1.23)
# cat /var/log/samba-full_audit.log | grep "|arquivos|"
(acessos feitos ao compartilhamento "arquivos", por parte de qualquer usurio)
... e assim por diante. Voc pode tambm direcionar a sada para um novo arquivo (ao
invs de tentar l-la pelo prprio terminal), como em:
# cat /var/log/samba-full_audit.log | grep "|arquivos|" > arquivos.log
Pgina 07 de 08
Ir

Backends: smbpasswd ou tdbsam

Samba, parte 2: Configurao avanada do Samba (atualizado)


Carlos E. Morimoto
24/06/2009
As primeiras verses do Samba suportavam apenas o uso de senhas de texto
puro, que eram transmitidas de forma no encriptada atravs da rede. Ainda possvel
reverter a este sistema primitivo nas verses recentes do Samba usando a opo
"encrypt passwords = no" no smb.conf, mas, alm de no trazer nenhuma vantagem,
isso quebra a compatibilidade com todas as verses recentes do Windows, que no
aceitam o envio de senhas em texto puro.
Durante a evoluo do Samba, foram criados diversos backends, que permitem
armazenar senhas encriptadas e outras informaes referentes aos usurios. Voc pode
escolher qual backend usar atravs da opo "passdb backend" do smb.conf. Vamos
entender como eles funcionam.
O smbpasswd o backend mais simples. Nele, as senhas so salvas no arquivo
"/etc/samba/smbpasswd" e so transmitidas de forma encriptada atravs da rede, com
suporte ao sistema NTLM, usado pelas verses contemporneas do Windows. A
vantagem do smbpasswd que ele um sistema bastante simples. Embora encriptadas,
as senhas so armazenadas em um arquivo de texto, com uma conta por linha.
Se voc quer apenas configurar um servidor Samba para compartilhar arquivos e
impressoras com a rede local, sem us-lo como PDC, ento o smbpasswd funciona bem.
Ele usado por padro no Samba 3, de forma que se o arquivo smb.conf do seu servidor
no contm a linha "passdb backend =" (como nos exemplos que vimos at aqui), voc
est usando justamente o smbpasswd.
Em seguida temos o tdbsam, que usa uma base de dados muito mais robusta,
armazenada no arquivo "/var/lib/samba/passdb.tdb" ( justamente este arquivo que o
script executado durante a instalao do pacote "samba" no Debian pergunta se deve ser
criado).
O tdbsam oferece duas vantagens sobre o smbpasswd: oferece um melhor desempenho
em servidores com um grande nmero de usurios cadastrados e oferece suporte ao
armazenamento dos controles SAM estendidos usados pelas verses server do
Windows. O uso do tdbsam fortemente recomendvel caso seu servidor tenha mais do
que algumas dezenas de usurios cadastrados ou caso voc pretenda usar seu servidor
Samba como PDC da rede (veja mais detalhes a seguir). Ele tambm um pr-requisito
caso voc precise migrar um domnio NT j existente para o servidor Samba.
Ao usar uma verso recente do Samba, ativar o uso do tbdsam bastante simples, basta
incluir a linha "passdb backend = tdbsam" na seo [global] do smb.conf, como em:
[global]
netbios name = Sparta

workgroup = Grupo
server string = Servidor
encrypt passwords = true
wins support = yes
preferred master = yes
os level = 100
enable privileges = yes
passdb backend = tdbsam
Embora o arquivo de senhas seja diferente, o comando para cadastrar os usurios no
Samba ao usar o tdbsam continua sendo o mesmo:
# smbpasswd -a usuario
Isso acontece porque, ao ser executado, o smbpasswd verifica a configurao presente
no smb.conf e assim realiza as operaes necessrias para cadastrar os usurios no
backend utilizado.
A principal dica que, ao utilizar o tdbsam, voc deve adicionar a linha "passdb
backend = tdbsam" no smb.conf logo no incio da configurao, antes de comear a
cadastrar os usurios no servidor, caso contrrio, o smbpasswd cadastrar os usurios no
smbpasswd e voc precisar cadastr-los novamente para atualizar a base do tdbsam
mais tarde. Em muitos casos, um script includo na distribuio pode se encarregar de
fazer a converso automaticamente, mas melhor no contar com isso.
Para verificar se os usurios esto cadastrados na base de dados do tdbsam, use o
comando "pdbedit -Lw" (como root). Ele deve retornar uma lista contendo todos os
usurios cadastrados, como em:
# pdbedit -Lw
gdh:1006:5567A38FC604AC6B90213960766D16B5:15350B7F4983CB5EAC073A89
2B423E8E:[U ]:LCT-471F5AF2:
root:0:E412294BCF24C19D433AC183134CC0F3:121797EEFB127E62222B23F77ED
087BE:[U ]:LCT-464460FF:
manuel:1005:5567A38FC604AC63902139606B6D16B5:15350B7F4983CB5EAC073
A892C687E8E:[U ]:LCT-4710F13C:
hp$:1007:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:0D80C51183ED74
320799B5BEDDCBE388:[W ]:LCT-47421493:
m5$:1009:B233C3E987D08D924405A9EF76E52792:65DD4A9908A35667D79B599F
94691E34:[W ]:LCT-4742D747:

Em seguida temos o mysqlsam e o ldapsam, onde as contas e senhas so armazenadas


em, respectivamente, um servidor MySQL e um servidor LDAP. O uso do MySQL em
conjunto com o Samba no muito comum, mas o LDAP vem crescendo bastante em
grandes redes.
A grande vantagem que o banco de dados pode ser acessado por vrios servidores,
sem necessidade de replicar o arquivo de senhas manualmente (usando o rsync, por
exemplo). Isso muito til no caso de redes muito grandes onde a autenticao dos
usurios dividida entre vrios servidores. Nesta configurao, o PDC divide a carga de
trabalho com um conjunto de BDCs (backup domain controllers), que podem ser tanto
outros servidores Samba quanto servidores Windows. Os BDCs so subordinados ao
servidor PDC, mas todos tem acesso mesma base de dados com os usurios,
armazenada no servidor LDAP, o que evita problemas de sincronismo entre eles.
De uma forma geral, um nico PDC usando o tdbsam como backend atende bem a at
250 clientes. Este limite no relacionado ao uso do tdbsam, mas sim a questes
prticas relacionadas ao desempenho da rede. Ele pode ser maior ou menor na prtica,
de acordo com a velocidade da rede (100 ou 1000 megabits), o hardware do servidor e a
carga sobre a rede. A partir da, passa a fazer sentido migrar para um banco de dados
LDAP e passar a adicionar servidores BDC secundrios.
Confira a terceira parte em: http://www.guiadohardware.net/tutoriais/samba-pdc/
Comente: http://www.guiadohardware.net/comunidade/v-t/985597/
Pgina 08 de 08