Configuração Avançada do Samba

A maior parte da configuração do Samba, incluindo as configurações gerais do servidor, impressoras e todos os compartilhamentos, é feita em um único arquivo de configuração, o "/etc/samba/smb.conf". Programas de configuração, como o Swat, simplesmente lêem este arquivo, "absorvem" as configurações atuais e depois geram o arquivo novamente com as alterações feitas dentro da interface. Isso permite que o Swat coexista com a edição manual do arquivo. Como comentei a pouco, o Swat remove todos os seus comentários e formatação (deixando apenas as opções), por isso muitos evitam usá-lo. Apesar disso, o formato do arquivo de configuração do Samba é bastante simples e por isso muitas vezes é mais rápido e até mais simples editar diretamente o arquivo do que fazê-lo através do Swat. Ao instalar o Samba, é criado um arquivo de configuração de exemplo, com vários comentários. Assim como no caso do Squid, ele é longo e difícil de entender, por isso acaba sendo mais fácil renomeá-lo e começar com um arquivo em branco, ou usar como base a configuração gerada através do Swat. Vamos então a uma segunda rodada de explicações sobre a configuração do Samba, agora editando diretamente o arquivo smb.conf e explorando com maior profundidade as opções disponíveis. Vamos começar 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 seções. A primeira é sempre a seção "[global]", que contém as opções gerais do servidor. Por enquanto, definimos apenas o nome do servidor (netbios name) e o nome do grupo de trabalho (workgroup), que seria o mínimo necessário para colocar o servidor na rede. As demais opções (não especificadas no arquivo) são configuradas usando os valores default. Se você omitir a opção "workgroup", por exemplo, o Samba vai reverter para o grupo "WORKGROUP", que é o padrão. Se quiser, você pode também adicionar uma descrição para o servidor, o que é feito através da opção "server string" (adicionada dentro da seção [global]), como em:

server string = Servidor Samba

Duas dicas são que:

1. O default do Samba é usar a string "Samba 3.0.24" (onde o "3.0.24" é a versão usada) como descrição quando a opção "server string" não está presente no arquivo.
2. Nas máquinas com o Windows XP, a descrição do servidor aparece antes do nome propriamente dito, como em "Servidor Samba (Sparta)". É importante levar isso em consideração, já que, no final das contas, o que importa é o que os usuários irão ver ao navegar pelo ambiente de redes:

Abaixo da seção [global], incluímos seções adicionais para cada compartilhamento, que é o caso da seção "[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 comentário. Sempre que alterar manualmente o smb.conf, ou mesmo alterar algumas opções pelo Swat e quiser verificar se as configurações estão corretas, rode o comando testparm. Ele funciona como uma espécie 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. É possível também fazer com que o servidor Samba atue como um controlador de domínio, como veremos em detalhes mais adiante. Em caso de erros no arquivo, o testparm ajuda a localizar o problema, indicando a linha ou opção inválida, 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 não diferencia o uso de maiúsculas e minúsculas nas opções, de forma que tanto faz escrever "writable = yes", "writable = Yes" ou "writable = YES". Entretanto, muitos dos parâmetros não são diretamente usados pelo Samba, mas sim repassados ao sistema que, diferentemente do Samba, diferencia os caracteres. Um exemplo são as localizações de pastas a compartilhar. Se você escrever "path = /mnt/Arquivos" (em vez de "path = /mnt/arquivos"), o compartilhamento não vai funcionar, pois o sistema reportará que a pasta não existe. Além do caractere "#", é possível usar também o ";" para comentar linhas. A principal observação é que você não pode inserir comentários em linhas válidas (mesmo que no final da linha), pois, ao fazer isso, toda a linha passa a ser ignorada pelo Samba. Neste exemplo, o comentário foi incluído na linha "path", o que acaba por desativar o compartilhamento completamente:

[teste] path = /mnt/arquivos
# Pasta compartilhada
comment = Compartilhamento que não funciona

O testparm também não indica o erro diretamente, já que ele também considera a linha como um comentário, o que pode levá-lo a perder um bom tempo tentando descobrir onde está o problema. Ao incluir comentários no arquivo, use sempre linhas separadas:

[teste]
# Pasta compartilhada
path = /mnt/arquivos
comment = Agora sim

As alterações no arquivo são lidas periodicamente pelo Samba (o default são 3 minutos) e aplicadas automaticamente. Isso permite que as mudanças de configuração sejam aplicadas de forma suave, sem prejudicar o acesso dos usuários, o que é importante em um ambiente de produção. Para fazer com que as alterações entrem em vigor imediatamente, reinicie o serviço do Samba, como em:

# /etc/init.d/samba restart

ou:

# service smb restart

A partir daí, o compartilhamento estará disponível. Ao tentar acessar o servidor através 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 usuários cadastrados no Samba precisam também existir no sistema, por isso, antes de usar o comando "smbpasswd -a", você deve usar o adduser para criar o usuário. Como citei anteriormente, a solução para casos em que você não deseja criar contas válidas para todos os usuários é criar usuários 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 conteúdo da pasta "/mnt/arquivos" do servidor, mas ao longo do tutorial adicionaremos muitos outros recursos ao servidor:

• Ajustando as permissões de acesso

Com esta configuração, os clientes conseguem visualizar os arquivos da pasta normalmente, mas ainda não 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 permissão apenas para leitura. Como não dissemos nada sobre as permissões de acesso do compartilhamento no arquivo de configuração, ele foi compartilhado usando o default. Para que o compartilhamento fique disponível com permissão de leitura e escrita, precisamos adicionar a opção "writable = yes" dentro da configuração do compartilhamento, que ficará:

[arquivos]
path = /mnt/arquivoswritable = 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 gravação, mas ela ainda pode ser abortada se as permissões da pasta não permitirem que o usuário grave arquivos. Se você criou a pasta "/mnt/arquivos" como root, então o default é que apenas ele possa gravar arquivos na pasta. Para permitir que outros usuários possam gravar, é necessário abrir as permissões da pasta. A esta altura, a lei do mínimo esforço diria para você usar um:

# chmod 777 /mnt/arquivos

Obviamente, isso permitiria que os usuários gravassem na pasta. O problema é que as permissões ficariam escancaradas, a ponto de qualquer um, que tenha acesso ao servidor (por qualquer meio) possa alterar os arquivos dentro da pasta, o que não é nada bom do ponto de vista da segurança. No tópico sobre o Swat, vimos como criar um grupo usando o users-admin (system-config-users) e abrir as permissões da pasta apenas para os usuários que fazem parte dele. Vamos ver agora como fazer isso via linha de comando. O primeiro passo é criar um grupo para os usuários que poderão fazer alterações na pasta, usando o comando "groupadd". Eu prefiro criar grupos com o mesmo nome do compartilhamento, para ficar mais fácil de lembrar, mas isso fica a seu critério.

# groupadd arquivos

A partir daí, você pode adicionar usuários ao grupo usando o comando "adduser", nesse caso especificando o usuário já criado e o grupo ao qual ele será adicionado, como em:

# adduser joao arquivos
# adduser maria

arquivos Para remover usuários do grupo, você usa o comando "deluser", como em:

# deluser joao arquivos
# deluser maria arquivos

Depois de criar o grupo e adicionar os usuários a ele, falta apenas ajustar as permissões 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 usuários cadastrados através do smbpasswd e o sistema autoriza a gravação para todos os usuários que fazem parte do grupo. Se você precisar que a alteração seja aplicada de forma recursiva, alterando as permissões de todas as subpastas e arquivos, adicione a opção "-R" nos dois comandos, como em:

# chgrp -R arquivos /mnt/arquivos
# chmod -R 775 /mnt/arquivos

Além de servirem para controlar as permissões de acesso dos usuários às pastas do sistema, os grupos podem ser usados para ajustar as permissões de acesso do Samba, de forma bastante simples. Se você quer que o compartilhamento fique disponível apenas para os usuários que cadastrou no grupo "arquivos", adicione a opção "valid users = +arquivos" na seção referente ao compartilhamento. O "+" indica que se trata de um grupo e não de um usuário isolado. O Samba verifica então quais usuários fazem parte do grupo e autoriza o acesso. A partir daí, quando você quiser liberar o acesso para um novo usuário, basta adicioná-lo ao grupo:

[arquivos]
path = /mnt/arquivos
writable = yesvalid users = +arquivos

Você pode também especificar uma lista de usuários isolados, separando-os por vírgula, por espaço, ou pelos dois combinados (o que preferir), como em:

[arquivos]
path = /mnt/arquivos
writable = yes
valid users = joao, maria, jose

É possível também combinar as duas coisas, indicando um ou mais grupos e também alguns usuários avulsos, como em:

[arquivos]
path = /mnt/arquivos
writable = yesvalid users = +arquivos, jose, joaquim, +admin

Assim como na maioria das opções do Samba, a opção "valid users" é exclusiva, ou seja, ao dizer que os usuários do grupo arquivos devem ter acesso, você automaticamente exclui todos os outros. Você pode também fazer o oposto, criando uma lista de usuários que não devem ter acesso e mantendo o acesso para os demais. Nesse caso, você usaria a opção "invalid users", como em:

[arquivos]
path = /mnt/arquivos
writable = yesinvalid users = jose, joaquim

Nesse caso, todos os usuários cadastrados no Samba podem acessar, com exceção dos usuários jose e joaquim. É possível ainda usar a opção "invalid users" para especificar exceções ao especificar grupos usando a opção "valid users", como em:

[arquivos]
path = /mnt/arquivos
writable = yesvalid users = +arquivos
invalid users = joao

Nesse caso, todos os usuários dentro do grupo arquivos terão acesso, com exceção do joao. Esta combinação pode ser usada em casos onde o grupo é especificado também em outros compartilhamentos e você precisa bloquear o acesso do usuário a um compartilhamento específico, sem removê-lo do grupo. É possível também criar uma lista de escrita, usando a opção "write list". Ela cria uma camada adicional de proteção, permitindo que, dentro do grupo de usuários com acesso ao compartilhamento, apenas alguns tenham permissão para alterar os arquivos, como em:

[arquivos]
path = /mnt/arquivoswritable = no
valid users = +arquivoswrite list = maria

Nesse caso, usamos a opção "writable = no", que faz com que o compartilhamento passe a ser somente-leitura. A seguir, especificamos que os usuários do grupo "arquivos" devem ter acesso (somente-leitura) e usamos a opção "write list = maria" para criar uma exceção, dizendo que a maria pode escrever na pasta. É importante notar que, neste exemplo, a maria deve fazer parte do grupo "arquivos", caso contrário teríamos uma situação interessante, onde ela não consegue alterar os arquivos no compartilhamento, pois não tem acesso a ele em primeiro lugar. :) Caso a maria não estivesse cadastrada no grupo, você deveria incluir o login na opção "valid users", como em:

[arquivos]
path = /mnt/arquivos
writable = no
valid users = +arquivos, maria
write list = maria

Podemos também fazer o oposto, restringindo a escrita para alguns usuários, mas mantendo o acesso para todos os demais. Nesse caso, usamos a opção "read list" para criar uma lista de exceções, como em:

[arquivos]
path = /mnt/arquivoswritable = yes
valid users = +arquivos, +adminread list = maria, jose

Nesse exemplo, usamos a opção "writable = yes" e especificamos que os usuários dentro dos grupos "arquivos" e "admin" tem acesso ao compartilhamento. Em seguida, usamos a opção "read list" para limitar o acesso dos usuários maria e jose, de forma que eles possam apenas ler, sem alterar os arquivos dentro da pasta. Outra opção relacionada é a "read only", que também aceita os valores "yes" e no". Na verdade, ela tem a mesma função da opção "writable", apenas usa uma lógica invertida. Dizer "writable = yes" ou dizer "read only = no" tem exatamente o mesmo efeito, como seis e meia-dúzia. Em geral, você usa uma ou outra de acordo com o contexto, como uma forma de tornar o arquivo mais legível, como em:

[modelos]
path = /mnt/modelosread only = yes

Continuando, é possível restringir o acesso também com base no endereço IP ou no nome da máquina a partir da qual o usuário está tentando acessar o compartilhamento. Isso permite adicionar uma camada extra de segurança no acesso a arquivos importantes, já que além do login e senha, é verificado a partir de qual máquina o acesso é proveniente. Isso é feito através das opções "hosts allow" e "hosts deny" que permitem, respectivamente, criar uma lista de máquinas que podem e que não podem acessar o compartilhamento. As listas podem incluir tanto os endereços IP quanto os nomes das máquinas. Para restringir o acesso ao compartilhamento a apenas duas máquinas específicas, você usaria:

[arquivos]
path = /mnt/arquivos
writable = yeshosts allow = 192.168.1.23, 192.168.1.24

ou

[arquivos]
path = /mnt/arquivos
writable = yeshosts allow = sparta, athenas

É possível também fazer o inverso, bloqueando o compartilhamento para acessos provenientes das duas máquinas. Nesse caso, mesmo que o usuário tente acessar usando um login válido, vai receber a mensagem de acesso negado, como se o login tivesse sido bloqueado ou a senha tenha sido alterada. A lista não possui um tamanho máximo, você pode incluir quantas máquinas precisar, separando os endereços ou nomes por vírgula e espaço. Você pode inclusive misturar endereços IP com nomes de máquinas, como nesse exemplo:

[arquivos]
path = /mnt/arquivos
writable = yeshosts deny = 192.168.1.23, athenas

É possível ainda combinar a restrição com base nos nomes e endereços com a restrição com base nos logins de acesso, de forma que o acesso seja autorizado apenas quando as duas condições forem satisfeitas. Para permitir que apenas a maria e o joao acessem o compartilhamento e ainda assim apenas se estiverem usando uma das duas máquinas permitidas, você usaria:

[arquivos]
path = /home/arquivos
writable = yesvalid 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 endereços omitindo o último octeto do endereço. Por exemplo, para que apenas clientes dentro da rede "192.168.1.x" tenham acesso, você inclui apenas a parte do endereço referente à rede, omitindo o octeto referente ao host, como em:

[arquivos]
path = /mnt/arquivos
writable = yeshosts allow = 192.168.1.

Se precisar criar exceções, limitando o acesso a algumas máquinas dentro da faixa de endereços especificada, você pode usar a opção "EXCEPT" para especificar as exceções, como em:

[arquivos]
path = /mnt/arquivos
writable = yeshosts allow = 192.168.1. EXCEPT 192.168.1.23, 192.168.1.24

Com isso, todos os endereços dentro da faixa teriam acesso, com exceção do .23 e do .24. O mesmo pode ser feito ao usar a opção "hosts deny", como em:

[restrito]
path = /mnt/sda2/restrito
writable = yes
valid users = isachosts deny = 192.168.1. EXCEPT 192.168.1.23

Aqui a lógica é invertida e todos os hosts dentro da faixa de endereços são bloqueados, com exceção do .23, que passa a ser o único aceito pelo servidor. Outro parâmetro que pode ser usado ao criar exceções é o "ALL", que inclui todos os endereços possíveis. Se a idéia é que apenas um determinado endereço possa acessar o compartilhamento, uma opção é usar "hosts deny = ALL EXCEPT 192.168.1.34". O default do Samba é permitir o acesso a partir de qualquer máquina, de forma que se você não usar nem a opção "hosts allow", nem a "hosts deny", qualquer máquina poderá acessar o compartilhamento. Ao usar apenas a opção "hosts allow", apenas as máquinas listadas terão acesso ao compartilhamento, as demais serão recusadas. Ao usar apenas a opção "hosts deny", apenas as máquinas listadas não terão acesso ao compartilhamento (as demais continuam acessando). Ao combinar o uso das opções "hosts allow" e "hosts deny", a opção "hosts allow" tem precedência (não importa a ordem em que elas sejam colocadas), de forma que as máquinas listadas terão acesso, mesmo que ele seja negado pela opção "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 endereços cujo acesso é autorizado pela opção "hosts allow". Neste caso, o Samba não considera a opção "hosts deny = 192.168.1.43" como uma exceção, mas sim como um erro de configuração. Para bloquear a máquina, você deveria usar:

[isos]
path = /mnt/isos
hosts allow = 192.168.1. EXCEPT 192.168.1.43
comment = Agora sim

Em situações onde você precisa restringir temporariamente o acesso a um determinado compartilhamento (para alguma tarefa de manutenção, por exemplo) você pode usar a opção "available = no", como em:

[arquivos]
path = /home/arquivos
writable = yes
valid users = maria, joaoavailable = no

Ela faz com que o compartilhamento "desapareça", da mesma forma que se você apagasse ou comentasse a configuração. 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 opção ou mudar para "available = yes". Outra opção interessante que pode ser incluída é a "browseable = no", que transforma o compartilhamento em um compartilhamento oculto:

[arquivos]
path = /home/arquivos
writable = yesbrowseable = no

Com isso, ele não aparece mais no ambiente de redes, mas pode ser acessado normalmente se você especificar o nome manualmente ao mapear o compartilhamento:

Essa não é propriamente uma opção de segurança, mas pode ser usada para afastar os curiosos dos compartilhamentos com acesso restrito. Concluindo, muitas opções que ficam disponíveis no Swat podem ser omitidas ao configurar manualmente, simplesmente porque são o default no Samba. O próprio Swat evita incluir opções redundantes ao gerar o arquivo, incluindo apenas as configurações que são diferentes dos valores default. Não é necessário incluir opções como "writable =no", "available = yes" ou "browseable = yes" no arquivo, pois estes já são os valores usados por padrão no Samba. Apesar disso, usá-los também não atrapalha em nada, de forma que nada impede que você os inclua no arquivo para se lembrar mais facilmente das opções. Outra dica é que você pode verificar a qualquer momento quais usuários e quais máquinas estão 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 usuário "gdh" está logado no servidor a partir de duas máquinas diferentes, um indício de que duas pessoas estão utilizando a mesma conta.

• A Seção [Global]

Todas as opções colocadas dentro da seção referente ao compartilhamento valem apenas para ele, o que permite que você crie diversos compartilhamentos diferentes e use um conjunto próprio de permissões para cada um. Estas mesmas opções, junto com um conjunto adicional podem ser especificadas de forma geral dentro da seção [global] do smb.conf. Nos exemplos anteriores, especificamos apenas o nome do servidor e o grupo de trabalho na seção [global]. Isto é suficiente para o servidor participar da rede e compartilhar arquivos, mas, naturalmente, existem muitas outras opções que podem ser usadas. Em primeiro lugar, temos o nível de segurança do servidor, definido através da opção "security". O default no Samba 3 é usar o controle de acesso baseado em usuário, que é o mesmo modo de acesso usado pelas versões domésticas do Windows 2000, XP e Vista. Neste modo, você cadastra os logins e senhas no servidor, define as permissões de acesso e o servidor checa as credenciais dos clientes antes de autorizar o acesso, a configuração que vimos até aqui. Este modo é ativado adicionando a opção "security = user" na seção [global], mas não é necessário usá-la no Samba 3, pois, como disse, ela é usada por padrão:

security = user

Em seguida, temos o modo "security = domain". Ao contrário do que o nome pode sugerir à primeira vista, este modo não é destinado a fazer com que o Samba atue como um controlador de domínio. Pelo contrário, ao configurar um servidor Samba como PDC, você continua usando a opção "security = user", da mesma forma que faria ao usar um servidor em modo stand alone. A opção "security = domain" é usada quando você quer que um servidor Samba participe do domínio 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 estações Windows 95/98. Estes dois modos são obsoletos e devem ser removidos em futuras versões do Samba. Antigamente, o modo "security = share" era usado em casos onde você queria disponibilizar compartilhamentos públicos na rede, sem muita segurança, 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 não era capaz de atuar como PDC; este modo permitia que ele atuasse como um proxy de autenticação, repassando as requisições para o servidor de autenticação principal. Atualmente este modo não é mais usado. Outra opção usada por padrão no Samba 3 é a "encrypt passwords = yes", de forma que também não é necessário especificá-la manualmente no arquivo. Entretanto, é saudável incluí-la em modelos e exemplos de configuração pois pode acontecer de alguém tentar usar o modelo no Samba 2, onde o default era que ela ficasse desativada.

encrypt passwords = yes

É muito comum que seja incluída também a opção "invalid users = root", uma medida de segurança para evitar que a conta de root seja usada ao acessar o servidor. A lógica é que a conta de root é a única conta presente em qualquer sistema Linux, de forma que alguém que decidisse usar um ataque de força bruta para tentar obter acesso ao servidor, testando todas as senhas possíveis, começaria justamente pela conta de root. Entretanto, a conta de root é necessária para dar upload de drivers de impressão e para logar os clientes ao usar o servidor Samba como PDC, situações onde a linha "invalid users = root" deve ser comentada ou removida. Continuando, as opções definidas dentro da seção [global] valem para todos os compartilhamentos do servidor, diferente das opções colocadas dentro da seção referente a cada um. Por exemplo, ao usar:

[global]
netbios name = Servidor
workgroup = Grupo
hosts allow = 192.168.1.

Apenas as máquinas dentro da faixa de endereços especificadas terão acesso ao servidor, o que seria interessante do ponto de vista da segurança, já que de qualquer forma o servidor deve ser acessado apenas por clientes da rede local. O maior problema é que a opção "hosts allow" usada na seção [global] tem precedência sobre qualquer opção "hosts deny" usada dentro dos compartilhamentos, o que pode criar problemas caso você queira restringir o acesso de alguma máquina da rede local a um determinado compartilhamento. Por exemplo, ao usar:

[global]
netbios name = Servidor
workgroup = Grupohosts allow = 192.168.1.

[share]
path = /mnt/sda2/sharedhosts deny = 192.168.1.2

A máquina "192.168.1.2" continuaria tendo acesso ao compartilhamento [share], pois o acesso é autorizado pela opção "hosts allow = 192.168.1." usada na seção [global]. Nesse caso, o melhor seria remover a linha "hosts allow = 192.168.1." da seção [global] e deixar apenas a opção "hosts deny = 192.168.1.2" na seção [share]:

[global]
netbios name = Servidor
workgroup = Grupo

[share]
path = /mnt/sda2/sharedhosts deny = 192.168.1.2

Em caso de conflito direto entre uma regra definida na seção [global] e outra definida em um dos compartilhamentos, a regra definida na seção [global] tem precedência. Por exemplo, ao usar:

[global]
netbios name = Servidor
workgroup = Grupohosts deny = 192.168.1.3

[share]
path = /mnt/sda2/sharedhosts allow = 192.168.1.3

A máquina "192.168.1.3" continuará sem acesso ao compartilhamento "share" (ou a qualquer outro recurso do servidor), já que vale a regra definida na seção [global]. Enquanto a linha "hosts deny = 192.168.1.3" não for removida, a máquina não terá acesso a nenhum dos compartilhamentos, não importa o que digam as demais linhas do arquivo. Continuando, um problema comum enfrentado ao administrar uma rede mista são os usuários escreverem a primeira letra do login em maiúsculo, como em "Joao" no lugar de "joao". No Windows isso não é 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 opção "username level", como em:

username level = 2

Esta opção faz com que o Samba verifique várias combinações de maiúsculas e minúsculas caso o login seja recusado pelo sistema. O número indica o volume de variações, que pode ser qualquer número inteiro. Ao usar o valor "2", o Samba verifica até dois níveis, incluindo variações como JOao, jOAo, Joao, jOaO e assim por diante. Usar um número maior pode retardar a autenticação, já que o Samba precisará testar muitas combinações, por isso são geralmente usados os valores "1" ou "2". Outra peculiaridade digna de nota é a questão dos nomes de arquivos. No Windows, os nomes de arquivos são salvos da forma como digitados pelo usuário, preservando os caracteres maiúsculos e minúsculos. Entretanto, o sistema é case insensitive, de forma que o sistema não 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 máquina 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 combinações de maiúsculas e minúsculas. No Samba 3 este recurso funciona muito bem, mas tem a desvantagem de consumir uma certa quantidade de memória do servidor. Em um pequeno servidor de rede local, isso não faz diferença, mas em um servidor que atende um grande número de requisições, a diferença pode se tornar considerável. Você pode simplificar as coisas orientando o Samba a salvar todos os arquivos em minúsculas. 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 através da opção "interfaces", que deve ser combinada com a opção "bind interfaces only = yes". Para que o servidor escute apenas a interface eth0, ignorando tentativas de conexão em outras interfaces, você usaria:

interfaces = eth0
bind interfaces only = yes

Por default, o Samba escuta em todas as interfaces, o que (se não houver nenhum firewall ativo) pode expor seus compartilhamentos para a Internet caso você ative o Samba em uma máquina conectada diretamente à internet, como no caso de um servidor que compartilha a conexão. É recomendável usar sempre estas duas opções, como uma forma de garantir que o Samba ficará disponível apenas na interface desejada. Outra opção 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 várias máquinas. Geralmente, isso acaba confundindo mais do que ajudando, mas pode ser útil em algumas situações, quando, por exemplo, um servidor é desativado e os compartilhamentos são movidos para outro. O novo servidor pode responder pelo nome do servidor antigo, permitindo que os desavisados continuem acessando os compartilhamentos através do endereço anterior. Para usá-la, basta adicionar a opção, seguida pelos apelidos desejados, como em:

[global]
netbios name = Servidor
netbios aliases = athenas, sparta
workgroup = Grupo

No tópico sobre o Swat falei sobre as opções "Local Master", "OS Level" e "Preferred Master", que definem se o servidor Samba deve participar das eleições para Master Browser e com qual nível 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 opção OS Level, como em:

local master = yes
os level = 90
preferred master = no

O valor da opção OS Level é absoluto, não 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 três linhas, o servidor simplesmente utiliza os valores default (local master = yes, os level = 20), que fazem com que ele participe das eleições, mas utilize credenciais baixas. A opção "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, responsável pela navegação na rede e listagem dos compartilhamentos e outros recursos disponíveis, de forma similar a um servidor DNS. O uso do WINS não é obrigatório; 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 navegação (a menos que você utilize um domínio), o que aumenta o tráfego da rede e torna todo o processo mais passível de falhas. Outra limitação importante é que os pacotes de broadcast são descartados pelos roteadores, o que faz com que eles (os pacotes de broadcast) não sejam transmitidos de um segmento a outro da rede caso ela esteja dividida em vários segmentos, interligados através de roteadores. O mesmo acontece caso você tenha duas redes ligadas através de uma VPN, onde o tráfego seja roteado. Em ambos os casos, os pacotes de broadcast são descartados pelos roteadores, fazendo com que os micros em um segmento não enxerguem os micros do outro e vice-versa. A solução em ambos os casos é implantar um servidor WINS na rede. Com isso, os clientes passam a consultar o servidor ao invés de mandar pacotes de broadcast, fazendo com que a navegação funcione mesmo ao utilizar vários segmentos de rede. Para isso, basta incluir a opção dentro da seção [global] do smb.conf:

wins support = yes

O próximo passo é configurar os clientes da rede para utilizarem o servidor. A opção fica escondida nas propriedades da conexão de rede, no Protocolo TCP/IP > Propriedades > Avançado > WINS, onde você deve adicionar o endereço IP do servidor:

A configuração do servidor WINS pode ser também enviada automaticamente para os clientes. Para isso, é necessário incluir a opção "netbios-name-servers" na configuração 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 seção com a configuração 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 configuração é feita adicionando a opção "wins server = servidor" (também na seção [global] do smb.conf), onde você especifica o endereço IP do servidor principal, como em: wins server = 192.168.1.254 Uma observação importante é que as opções "wins support" e "wins server" são mutuamente exclusivas. Ou a máquina atua como servidor WINS, ou como cliente (nunca as duas coisas ao mesmo tempo), de forma que você não deve jamais combinar as duas opções dentro da configuração. Em versões antigas do Samba, combinar as duas opções na configuração simplesmente fazia com que o servidor deixasse de funcionar. Nas atuais o resultado não chega a ser dramático (o servidor vai simplesmente ignorar a opção que for colocada depois), mas mesmo assim este é um erro grave de configuração que deve ser evitado. Um exemplo de seção [global] usando as opções 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 configuração ativa o teste de variações de maiúsculas e minúsculas para os logins recusados (apenas um nível), faz com que todos os arquivos salvos nos compartilhamentos sejam renomeados para caracteres minúsculos, 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 configuração perfeitamente utilizável, faltaria apenas adicionar as seções referentes aos compartilhamentos.

• A Seção [Homes]

Uma vantagem de utilizar usuários "reais" no servidor Samba, em vez de usuários castrados, é que você tem a opção de compartilhar os diretórios home através da seção [homes] no smb.conf. Este é um serviço interno do Samba, que permite compartilhar automaticamente o diretório home de cada usuário, sem precisar criar um compartilhamento separado para cada um. A configuração mais comum é compartilhar os diretórios home com permissão de acesso apenas para o respectivo usuário. Dessa forma, cada usuário tem acesso apenas ao seu próprio diretório home (que aparece no ambiente de redes como um compartilhamento com o mesmo nome), sem poder acessar, nem muito menos alterar o conteúdo dos diretórios home dos demais usuários. Nesse caso, a configuração fica:

[homes]
valid users = %S
read only = no
create mask = 0700
directory mask = 0700
browseable = no

Não é necessário especificar a pasta a compartilhar, pois ao omitir a linha "path" o Samba sabe que deve compartilhar o home de cada usuário. As opções "create mask = 0700" e "directory mask = 0700" fazem com que todos os arquivos e pastas criados pelo usuário dentro do home sejam acessíveis apenas por ele mesmo. A opção "browseable = no" faz com que cada usuário possa ver apenas seu próprio diretório, o que é reforçado pela opção "valid users = %S", que diz explicitamente que apenas o próprio usuário deve ter acesso à sua pasta home. Uma queixa comum é que ao acessar o diretório home através do Samba, os usuários verão todos os arquivos e pastas de configuração de programas que são salvos dentro do diretório home, o que pode ser confuso. Uma forma de evitar isso é alterar a configuração, de forma que o Samba compartilhe uma pasta vazia dentro do home, e não o diretório home em si. Com isso é mantido o propósito de oferecer uma pasta particular para o usuário, onde ele possa salvar seus arquivos particulares e seus backups, sem a poluição gerada pela presença dos arquivos de configuração. A configuração 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 não mais o diretório home em si (você pode especificar outra pasta qualquer) e a linha "valid users = %S" garante que a pasta ficará acessível apenas para o próprio usuário. Naturalmente, a pasta "share" precisa ser criada dentro do home de cada usuário manualmente. Você pode fazer isso de forma automática para todos os usuários usando este mini shell script:

cd /home
for i in *; do
mkdir $i/share
chown $i:$i $i/share
done

Aproveite para criar também a pasta "share" dentro do diretório "/etc/skel", que é usado como um modelo para a criação do home de novos usuários. Isso faz com que o diretório seja adicionado ao home de todos os usuários criados daí em diante, de forma automática:

# mkdir /etc/skel/share

Concluindo, aqui vai uma lista de outras variáveis do Samba para referência:

• %a : A versão do Windows usada, onde o "%a" é substituído pelas strings "Win95" (Windows 95/98), "WinNT" (Windows NT 3.x ou 4.x), "Win2K" (Windows 2000 ou XP) ou "Samba" (máquinas Linux rodando o Samba)
• %I : Endereço IP da máquina cliente (ex: 192.168.1.2)
• %m : Nome da máquina cliente (ex: cliente1)
• %L : Nome do servidor (ex: athenas)
• %u : Nome do usuário, como cadastrado no servidor Linux (ex: joao)
• %U : Nome do usuário, como enviado pelo cliente Windows (pode ser diferente do login cadastrado no servidor em algumas situações)
• %H : Diretório home do usuário (ex: /home/maria)
• %g : Grupo primário do usuário (ex: users)
• %S : Nome do compartilhamento atual (o valor informado entre colchetes, ex: arquivos)
• %P : Pasta compartilhada (o valor informado na opção "path", ex: /mnt/arquivos)
• %v : Versão do Samba (ex: 3.2.24)
• %T : Data e horário atual

Ao longo do texto, veremos alguns outros exemplos de uso destas variáveis, mas você pode usá-las em outras situações para criar compartilhamentos "inteligentes", que mostram pastas diferentes de acordo com as propriedades do cliente. Por exemplo, a variável "%a" (que indica a versão do Windows no cliente), poderia ser usada para criar um compartilhamento com drivers, que mostrasse diretamente a pasta com os drivers corretos para a versão 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 série de sub-pastas, com os valores possíveis para a variável, incluindo "Win95", "WinNT", "Win2K" e "Samba". Ao acessar o compartilhamento, o cliente vê apenas o conteúdo da pasta correspondente ao sistema operacional usado.

• A Conta Guest

No Windows XP é usado por padrão um modo simplificado de compartilhamento de arquivos, o "simple sharing", que visa imitar o modo de acesso do Windows 95/98, onde os compartilhamentos são públicos e você apenas define se eles são apenas leitura ou leitura e escrita. Na verdade, o Windows XP usa o controle de acesso com base no usuário, assim como o Samba 3, mas, por baixo dos panos, todos os acessos passam a ser mapeados para a conta "guest" (ativa por padrão), o que permite que usuários remotos sem login válido acessem os compartilhamentos diretamente. Este recurso é também chamado de "force guest". Naturalmente, podemos fazer o mesmo no Samba. Para isso, adicione as linhas abaixo dentro da seção [global] do smb.conf:

map to guest = bad
user guest account = guest

A primeira opção faz com que sempre que um cliente especificar um usuário inválido ao tentar acessar o servidor, o servidor mapeie a requisição para o login especificado na opção "guest account", que é usada para acessar o compartilhamento. Neste exemplo, qualquer usuário não autenticado passaria a usar a conta "guest", que deve ter sido previamente cadastrada no servidor. Você pode também usar qualquer outra conta válida, como em "guest account = maria". Uma opção menos usada é a "map to guest = bad password". Ela se diferencia da "map to guest = bad user" pois permite o acesso apenas caso o usuário especifique um login válido, mas erre apenas a senha. O principal motivo dela não ser muito usada é que ela confunde o usuário, já que ele ou vai achar que está realmente logado no servidor (quando na verdade está apenas acessando de forma limitada através da conta guest) ou vai passar a achar que o servidor aceita qualquer senha. Para que os usuários não-autenticados possam acessar os compartilhamentos, você deve explicitamente autorizar o acesso, adicionando a opção "guest ok = yes" na configuração, como em:

[global]
netbios name = Sparta
workgroup = Grupo
map to guest = bad
user guest account = guest

[publico]
path = /mnt/sda2/publico
writable = yesguest ok = yes

Note que no exemplo usei a opção "writable = yes". Entretanto, para que os usuários não-autenticados possam efetivamente escrever na pasta, é necessário verificar se as permissões de acesso da pasta permitem que a conta especificada ("guest" no exemplo) altere os arquivos. Como disse anteriormente, o Samba está subordinado às permissões de acesso do sistema. Outra opção comum em compartilhamentos públicos é a "guest only = yes" (usada no lugar da "guest ok = yes", na seção [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 então a mais um exemplo de configuração do smb.conf, desta vez usando a conta guest para criar um servidor de arquivos público. Ele possui duas partições de arquivos (montadas nas pastas "/mnt/hda2 e "/mnt/sda1") que ficam disponíveis a todos os usuários da rede:

[global]
netbios name = Plutus
server string = Servidor público
workgroup = Grupo
local master = yes
os level = 100
preferred master = yes
wins support = yesmap to guest = bad user
guest account = gdh

[arquivos]
path = /mnt/hda2
writable = yesguest ok = yes

[backups]
path = /mnt/sda1
writable = yes guest ok = yes

Esta configuração é bastante simples e a prova de falhas. O servidor vai assumir a função de master browser, se responsabilizando pela navegação dos clientes e vai mapear qualquer acesso para a conta "gdh" usada na opção "guest account", permitindo que qualquer um possa ler e gravar arquivos nos dois compartilhamentos. As duas principais observações são que o usuário "gdh" deve ser um usuário real do sistema, cadastrado no servidor Samba, e que ele deve ser o dono das duas pastas compartilhadas, de forma que não tenha problemas para acessar seu conteúdo. 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 configuração é ideal para pequenos servidores de rede local, que devem apenas disponibilizar arquivos na rede, sem muita segurança. Ela é similar ao exemplo de configuração para um servidor de arquivos público que incluí no livro Redes, Guia Prático.

• Lixeira no Samba

Em qualquer servidor de arquivos, a principal prioridade é assegurar a integridade e a segurança dos dados. Entretanto, por mais estável que seja a rede e por mais robusto que seja o servidor, o elo mais fraco da cadeia acaba sendo sempre o usuário. De nada adianta um servidor perfeitamente estável se ele deleta um arquivo importante sem querer. Pensando nisso, o Samba oferece a opção de usar uma lixeira, que pode lhe poupar muita dor de cabeça em diversas situações. Isso é feito através da opção "vfs object = recycle", que cria uma lixeira dentro de cada pasta compartilhada, que passa a armazenar todos os arquivos deletados. Isso previne a remoção acidental de arquivos, já que o usuário passa a precisar deletar o arquivo e em seguida limpar o conteúdo da lixeira para realmente removê-lo, o que é o comportamento esperado por muitos. Por padrão, os arquivos deletados vão para a pasta ".recycle" (dentro do compartilhamento), mas o nome pode ser alterado através da opção "recycle:repository = lixeira" (onde o "lixeira" é o nome desejado, que pode ser qualquer um). Quando uma pasta é deletada, o padrão é simplesmente misturar todos os arquivos no diretório raiz da lixeira, mas isso pode ser evitado adicionando a opção "recycle:keeptree = yes". Aqui temos mais um exemplo de compartilhamento, incluindo as três opções:

[projetos]
path = /mnt/sda2/projetos
writable = yes
valid users = +apolo, isacvfs object = recycle
recycle:repository = lixeira
recycle:keeptree = yes

Outra opção útil é a "recycle:versions", que faz com que a lixeira mantenha diferentes versões do mesmo arquivo, em vez de manter apenas a última versão. Os arquivos repetidos passam então 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 conteúdo das lixeiras de vez em quando e limpar as pastas quando elas começarem a consumir muito espaço em disco. Você pode inclusive deletar a pasta da lixeira inteira, pois ela é recriada automaticamente quando o próximo arquivo for deletado.

Uma opção para reduzir o problema do espaço desperdiçado é centralizar todas as lixeiras em uma única pasta. Isso permite inclusive que você utilize uma partição ou um HD separado para armazenar os arquivos da lixeira, sem correr o risco de ela crescer até ocupar todo o espaço disponível na partição principal. Para isso, usamos a opção "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 opção pode tanto ser adicionada individualmente em cada compartilhamento quanto ser especificada apenas uma vez na seção [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 confusão, já que ela misturaria arquivos deletados por todos os usuários. Uma solução é adicionar a variável "%U", que faz com que os arquivos sejam organizados em várias subpastas, separados por usuário (as subpastas usadas por cada usuário são criadas automaticamente conforme necessário). Nesse caso a opção fica:

recycle:repository = /var/samba/trash/%U

O problema em usar essa opção é que os usuários deixam de ver a lixeira, já que ela passa a ficar em uma pasta separada. Uma solução para o problema é criar um novo compartilhamento, que permite que cada usuário veja sua lixeira particular. Para isso, iremos novamente usar a variável "%U":

[lixeira]
path = /var/samba/trash/%U
writable = yes

Usei a opção "writable = yes" para permitir que o próprio usuário possa limpar a lixeira quando quiser, mas isso é opcional. Vale lembrar que para que o usuário consiga limpar os arquivos da lixeira, é necessário que ele tenha permissão de escrita para a pasta "/var/samba/trash/". Nesse caso, você tem a opção de simplesmente abrir as permissões da pasta (chmod 777), ou ajustar manualmente as permissões da sub-pasta de cada usuário, como em:

# chown -R joao:joao /var/samba/trash/joao

Mais uma medida útil para evitar desperdício de espaço é bloquear a gravação de arquivos de backup e de arquivos temporários na lixeira, já que eles costumam ser numerosos e raramente são importantes. É saudável bloquear também arquivos .iso (que são tipicamente muito grandes), de forma que eles sejam também deletados diretamente. As extensões de arquivos são especificadas através da opção "recycle:exclude" e nomes de pasta através da opção "recycle:exclude_dir", como em:

recycle:exclude = *.tmp, *.log, *.obj, ~*.*, *.bak, *.iso
recycle:exclude_dir = tmp, cache

Assim como a "recycle:repository", as demais opções da lixeira podem tanto serem especificadas individualmente dentro de cada compartilhamento quanto diretamente dentro da seção [global], o que é naturalmente o mais simples caso você deseje ativá-la para todos os compartilhamentos. O default do Samba 3 é manter todas as opções desativadas, de forma que a lixeira só é usada quando as opções são especificadas. Um exemplo de configuração, com a lixeira ativa dentro da seção [global], dois compartilhamentos de arquivos e mais o compartilhamento que dá acesso à pasta central da lixeira por parte dos usuários seria:

[global]
netbios name = Phanteon
server string = Servidor com lixeira
workgroup = Grupo
local master = yes
os level = 100
preferred master = yes
wins support = yesvfs 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

• Auditando Acessos

O Samba oferece também um recurso de geração de log. Ele pode ser ativado adicionando as opções abaixo na seção [global] do smb.conf:

log level = 1
log file = /var/log/samba.log
max log size = 1000

A opção "log level" indica o nível das mensagens (de 0 a 10), sendo que o nível 0 mostra apenas mensagens críticas, o nível 1 mostra alguns detalhes sobre os acessos e os demais mostram diversos níveis de informações de debug, úteis a desenvolvedores. A opção "log file" indica o arquivo onde ele será gerado e a "max log size" indica o tamanho máximo, em kbytes. A partir do Samba 3.04 foi incluído um módulo de auditoria, que permite logar os acessos e as modificações feitas de uma forma muito mais completa que o log tradicional. Isso é feito através do módulo "full_audit", que (do ponto de vista técnico) funciona de forma similar ao módulo "recycle" usado pela lixeira. O primeiro passo é ativar o módulo, o que é feito através da linha abaixo:

vfs objects = full_audit

O próximo passo é definir quais operações devem ser logadas através da opção "full_audit:success", como em:

full_audit:success = open, opendir, write, unlink, rename, mkdir, rmdir, chmod, chown(as opções formam uma única linha)

As opções que incluí no exemplo são 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 diretório), rmdir (remover um diretório), chmod (alterar as permissões de acesso de um arquivo) e chown (mudar o dono de um arquivo). Você pode remover algumas destas opções, deixando apenas as opções desejadas, ou ver uma lista completa das opções que podem ser incluídas no manual do vfs_full_audit, disponível no: http://samba.org/samba/docs/man/manpages-3/vfs_full_audit.8.html Continuando a configuração, especificamos as informações que desejamos que sejam incluídas no log, usando a opção "full_audit:prefix". Aqui podemos utilizar as variáveis que mostrei no tópico sobre o compartilhamento [homes], como a "%u" (o nome do usuário), "%I" (o IP da máquina) e "%S" (o nome do compartilhamento onde foi feito o acesso ou a alteração). Não é necessário incluir a variável referente ao nome da máquina, pois o nome é incluído automaticamente:

full_audit:prefix = %u|%I|%S

Por padrão, o módulo loga não apenas os acessos e modificações, mas também um grande volume de mensagens de alerta e erros gerados durante a operação. A opção "full_audit:failure = none" evita que estas mensagens sejam logadas, fazendo com que o log fique muito mais limpo e seja mais fácil encontrar as opções que realmente interessam:

full_audit:failure = none

Concluindo, especificamos o nível 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 configuração pode ser tanto incluída dentro da seção [global] (de forma que o log inclua os acessos e as alterações feitas em todos os compartilhamentos) quanto ser incluída apenas na configuração de um compartilhamento específico. Com isso, o Samba vai passar a gerar os eventos referentes aos acessos. Falta agora configurar o sysklogd (o serviço responsável pela geração 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 opções "full_audit:facility" e "full_audit:priority", enquanto o "/var/log/samba-full_audit.log" é o arquivo de log que será gerado. Depois de concluída a configuração, reinicie os serviços 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 máquina, o usuário, o IP da máquina, o nome do compartilhamento, a operação 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 usuários e máquinas, mas é fácil ver apenas as entradas referentes a um determinado usuário, compartilhamento, endereço IP ou outro parâmetro 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 usuário joao, feitos a partir do endereço 192.168.1.23)
# cat /var/log/samba-full_audit.log | grep "|arquivos|"
(acessos feitos ao compartilhamento "arquivos", por parte de qualquer usuário)

E assim por diante. Você pode também direcionar a saída para um novo arquivo (ao invés de tentar lê-la pelo próprio terminal), como em:

# cat /var/log/samba-full_audit.log | grep "|arquivos|" > arquivos.log

• Backends: smbpasswd ou tdbsam

As primeiras versões do Samba suportavam apenas o uso de senhas de texto puro, que eram transmitidas de forma não encriptada através da rede. Ainda é possível reverter a este sistema primitivo nas versões recentes do Samba usando a opção "encrypt passwords = no" no smb.conf, mas, além de não trazer nenhuma vantagem, isso quebra a compatibilidade com todas as versões recentes do Windows, que não aceitam o envio de senhas em texto puro. Durante a evolução do Samba, foram criados diversos backends, que permitem armazenar senhas encriptadas e outras informações referentes aos usuários. Você pode escolher qual backend usar através da opção "passdb backend" do smb.conf. Vamos entender como eles funcionam. O smbpasswd é o backend mais simples. Nele, as senhas são salvas no arquivo "/etc/samba/smbpasswd" e são transmitidas de forma encriptada através da rede, com suporte ao sistema NTLM, usado pelas versões contemporâneas do Windows. A vantagem do smbpasswd é que ele é um sistema bastante simples. Embora encriptadas, as senhas são 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, então o smbpasswd funciona bem. Ele é usado por padrão no Samba 3, de forma que se o arquivo smb.conf do seu servidor não contém 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 instalação 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 número de usuários cadastrados e oferece suporte ao armazenamento dos controles SAM estendidos usados pelas versões server do Windows. O uso do tdbsam é fortemente recomendável caso seu servidor tenha mais do que algumas dezenas de usuários cadastrados ou caso você pretenda usar seu servidor Samba como PDC da rede (veja mais detalhes a seguir). Ele é também um pré-requisito caso você precise migrar um domínio NT já existente para o servidor Samba. Ao usar uma versão recente do Samba, ativar o uso do tbdsam é bastante simples, basta incluir a linha "passdb backend = tdbsam" na seção [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 = yespassdb backend = tdbsam

Embora o arquivo de senhas seja diferente, o comando para cadastrar os usuários no Samba ao usar o tdbsam continua sendo o mesmo:

# smbpasswd -a usuario

Isso acontece porque, ao ser executado, o smbpasswd verifica a configuração presente no smb.conf e assim realiza as operações necessárias para cadastrar os usuários no backend utilizado. A principal dica é que, ao utilizar o tdbsam, você deve adicionar a linha "passdb backend = tdbsam" no smb.conf logo no início da configuração, antes de começar a cadastrar os usuários no servidor, caso contrário, o smbpasswd cadastrará os usuários no smbpasswd e você precisará cadastrá-los novamente para atualizar a base do tdbsam mais tarde. Em muitos casos, um script incluído na distribuição pode se encarregar de fazer a conversão automaticamente, mas é melhor não contar com isso. Para verificar se os usuários estão cadastrados na base de dados do tdbsam, use o comando "pdbedit -Lw" (como root). Ele deve retornar uma lista contendo todos os usuários cadastrados, como em:

# pdbedit -Lw 

gdh:1006:5567A38FC604AC6B90213960766D16B5:15350B7F4983CB5EAC073A892B423E8E:[U ]:LCT-471F5AF2:
root:0:E412294BCF24C19D433AC183134CC0F3:121797EEFB127E62222B23F77ED087BE:[U ]:LCT-464460FF:
manuel:1005:5567A38FC604AC63902139606B6D16B5:15350B7F4983CB5EAC073A892C687E8E:[U ]:LCT-4710F13C:
hp$:1007:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:0D80C51183ED74320799B5BEDDCBE388:[W ]:LCT-47421493:
m5$:1009:B233C3E987D08D924405A9EF76E52792:65DD4A9908A35667D79B599F94691E34:[W ]:LCT-4742D747:

Em seguida temos o mysqlsam e o ldapsam, onde as contas e senhas são armazenadas em, respectivamente, um servidor MySQL e um servidor LDAP. O uso do MySQL em conjunto com o Samba não é muito comum, mas o LDAP vem crescendo bastante em grandes redes. A grande vantagem é que o banco de dados pode ser acessado por vários 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 autenticação dos usuários é dividida entre vários servidores. Nesta configuração, 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 são subordinados ao servidor PDC, mas todos tem acesso à mesma base de dados com os usuários, 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 não é relacionado ao uso do tdbsam, mas sim a questões práticas relacionadas ao desempenho da rede. Ele pode ser maior ou menor na prática, 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 secundários.

Fonte: http://www.mktecnologia.net.br