Network File System - NFS

Published 10 January 2016

Quando e como usar

NFS

Quando se fala de compartilhamento de arquivos, pastas e dados em redes GNU/Linux para Windows, lembra-se de cara do servidor SAMBA. Acontece que o Samba 4 apesar do foco ser na compatibilidade entre os Sistemas Operacionais GNU/Linux e Windows, também pode ser usado para compartilhamento de dados entre sistemas GNU/Linux e Mac.

Neste caso, fica a dúvida: Qual a necessidade de ainda se usar um servidor NFS? Segundo o livro Managing NFS and NIS, 2nd Edition de Mike Eisler, Ricardo Labiaga e Hal Stern, o NFS é uma opção para compartilhar sistemas de arquivos entre máquinas GNU/Linux, de uma forma prática, rápida e estável. Afinal, ainda que o Samba esteja suprindo “quase” toda a necessidade para com um NFS server, a velocidade de transferências de dados no NFS, ainda é muito superior. Sem falar que o NFS preserva as permissões de arquivos UNIX-to-UNIX.

Outro uso bastante vantajoso do NFS, é em instalações de Sistemas Operacionais através do PXEBOOT. Muito bom para instalações remotas.

Se o compartilhamento é apenas entre sistemas GNU/Linux, não há razões para usar SAMBA. Exceto se houver a necessidade além do compartilhamento de pastas, arquivos, e dados visto que o Samba 4 trabalha também como Active Directory como já fora muito bem explicado em Samba 4 - Um novo horizonte. Por outro lado, o Microsoft Windows a partir da versão Seven Ultimate e Professional, já suporta o protoclo NFS (mas também não há razão alguma para usar NFS neste caso).

Logo, se a pergunta for quando usar o NFS?, ao meu ver, a resposta mais pertinente seria quando houver necessidade de obter maior desempenho/velocidade, e consequentemente maior performance no transporte de arquivos através da criação de um servidor UNIX-TO-UNIX e adaptado a um Network Attached Storage - NAS ou, para a instalação de Sistemas Operacionais através do PXEBOOT.

Um dos problemas sérios do NFS na atual versão, é com sua segurança. Isto é, o protocolo NFS fica restrito a uma rede local confiável já que os dados viajam pela rede sem criptografia (um sniffer pode interceptá-los) e os direitos de acesso são obtidos com base no endereço IP do cliente (que pode ser falsificado através de spoofed).

Outro inconveniente, é que a versão 4 diferentemente das anteriores, não é tão fácil de instalar e configurar quando se deseja usar recursos básicos de segurança tais como autenticação, e criptografia já que ele faz uso do Kerberos para este fim.

Existe também outro protocolo para comunicação UNIX-TO-UNIX quando se trata por exemplo da comunicação GNU/Linux, para Mac OSx. Trata-se do protocolo AFP - Apple Filling Protocol. Vale lembrar que o OS X suporta SMB, em grande parte porque há muitos ambientes em que só a Microsoft e outros servidores SMB estão disponíveis em uma rede. No entanto, SMB é propriedade da Microsoft, e foi projetado especificamente para clientes Windows.

Você poderá também experimentar o Netatalk um daemon compatível com sistemas UNIX-TO-UNIX isto é, POSIX, com a capacidade de compartilhar arquivos e impressoras com dispositivos Apple. Para instalar é muito fácil:

apt-get install -y netatalk 

Consulte as instruções do netatalk em https://wiki.debian.org/AppleTalkServer.


História

O primeiro arquivo chamado File access Listener, foi desenvolvido em 1976 pela Digital Equipment Corporation - DEC. Uma implementação do Protocolo de Acesso de Dados - DAP, que era parte do conjunto de protocolos DECnet. Como o advento do TCP/IP, o DEC publicou as especificações do protocolo dos seus protocolos de rede, que incluía o DAP.

O NFS foi o primeiro sistema de arquivos de rede moderno (construído sobre o protocolo IP). Ele começou como um sistema de arquivos experimental desenvolvido pela equipe interna da Sun Microsystems no início de 1980. Dada a popularidade da abordagem, o protocolo NFS foi documentado como uma especificação Request for Comments (RFC) e evoluiu para o que é conhecido como NFSv2. Como padrão, NFS cresceu rapidamente por causa de sua capacidade de interoperar com outros clientes e servidores.

O padrão continuou a evoluir para NFSv3, definido pela RFC 1813. Esta iteração do protocolo foi muito mais escalável do que as versões anteriores, apoiando arquivos grandes (maiores que 2 GB),com escrita assíncrona, e TCP como protocolo de transporte abrindo o caminho para um arquivo sistemas em redes mais amplo. Em 2000, RFC 3010 (revisto por RFC 3530) trouxe o NFS para o ambiente corporativo.

A Sun lançou NFSv4 com forte segurança, juntamente com um protocolo stateful (versões anteriores do NFS eram desenvolvidas sem uma entidade por de trás, independentes). Hoje, existe como NFS versão 4.1 (conforme definido pela RFC 5661), que adiciona suporte de protocolo para acesso paralelo entre servidores distribuídos (chamado de extensão pNFS).

Instalaçao do servidor NFS

A primeira etapa consiste na instalação dos pacotes denominados nfs-kernel-server e nfs-common para que o GNU/Linux possa ser posteriormente configurado como servidor de arquivos como mostro a seguir:

apt-get install -y nfs-kernel-server nfs-common

O que estamos instalando exatamente?

  • nfs-kernel-server - Este pacote contém o suporte em espaço de usuário necessário para uso do servidor NFS de núcleo (“kernel”). A maioria dos administradores que deseja instalar um servidor NFS vai querer instalar este pacote. O nfs-kernel-server provém do freebsd-nfs-server.
  • nfs-common - Contém arquivos de suporte a NFS comuns ao cliente e ao servidor e provém do freebsd-nfs-common.

Para exemplificar o processo de compartilhamento de diretórios no servidor com os demais clientes da rede, vamos criar os diretórios “/nfs/publico” (modo padrão com usuário nobody e grupo nogroup) e também “/nfs/privado” (modo restrito):

mkdir -p /nfs/publico
chown nobody:nogroup /nfs/publico
chmod 007 /nfs/publico

mkdir -p /nfs/privado
chown user:group /nfs/privado
chmod 750 /nfs/privado
  • chown user - Altera o usuário e\ou posso de usuário de grupo de cada arquivo fornecido.
  • chmod 750 - Permissão de leitura, escrita e execução para o usuário user.
  • chown nobody:nogroup - O proprietário nobody, ler, executa e escreve enquanto o nogroup somente de leitura e execução.
  • chmod 007 - Significa que apenas o /nfs/publico pode ler, escrever e executar.

As configurações do servidor NFS são realizadas no arquivo de configuração que fica localizado em “/etc/exports”. Na sequência trago as linhas de configuração necessárias para compartilhar os dois diretórios criados na etapa anterior:

Vá até o /etc/exports com seu editor de texto e adicione estas duas linhas (uso o vim):

/nfs/publico   192.168.1.100(rw,sync,no_root_squash)   192.168.221.0/24(ro,sync)
/nfs/privado   192.168.1.100(rw,sync,no_root_squash)

Nota: Nas configurações acima estamos considerando que o servidor NFS possui o endereço IP 192.168.1.100. A sintaxe das linhas de configuração do arquivo exports é bem simples: a primeira coluna contém o diretório local que será compartilhado, enquanto que a segunda coluna contém o endereço ou nome de uma máquina cliente (ou toda a rede) acompanhado das suas opções entre parênteses.

É possível criar várias colunas fazendo referência a diferentes máquinas clientes, como fizemos em relação ao diretório /nfs/publico que tem acesso de leitura e escrita (rw) para o host 192.168.1.100 e acesso somente leitura (ro) para as demais máquinas da rede 192.168.1.0/24. A opção no_root_squash diz que o compartilhamento poderá ser editado pelo root remoto (cliente) com os mesmos privilégios do root local (servidor) e sync acaba sendo uma opção de segurança.

A escrita assíncrona async, isto é, desabilitando o sync através do “async”, aumenta um pouco a performance, mas ela diminui a confiança já que existe o risco de perda de dados no caso do servidor falhar entre comunicar a escrita e realmente escrever no disco. Como o valor padrão foi alterado recentemente (comparado ao valor histórico do NFS), uma configuração explícita é recomendada.A opção sync sincroniza os dados sistema caso ocorra acidentalmente uma sobrecarga e o servidor seja reiniciado. Por fim, basta reiniciar o serviço NFS para validar as novas configurações:

/etc/init.d/nfs-kernel-server restart

Nota: Você poderá reiniciar um serviço no Debian 8 de diversas maneiras. Prefiro usar o antigo modo através do /etc/init.d/ por uma questão de comodidade visto que usando os comandos do systemd como por exemplo systemctl comando programa.serviço, ainda não funciona bem em todos os casos. Ou se preferir service programa ação.

Configuração do Cliente NFS

Como já instalamos o pacote nfs-common, você poderá realizar este mesmo procedimento na máquina que deseja que seja o client:

apt-get install nfs-common

É necessário criar no cliente os diretórios locais em que os compartilhamentos do servidor serão montados. Pode ser utilizado qualquer diretório, inclusive o /home/usuário:

mkdir -p /mnt/publico
mkdir -p /mnt/privado

Em seguida, basta montar os compartilhamentos do servidor nos respectivos diretórios que criamos localmente na estação cliente, de maneira bastante similiar o processo de montagem de discos que era comumente utilizado para acessarmos mídias extenas:

mount 192.168.1.101:/nfs/publico /mnt/publico
mount 192.168.1.101:/nfs/privado /mnt/privado

Agora a estação cliente já tem acesso a todos os arquivos compartilhados no servidor a partir dos diretórios montados localmente. É possível verificar os pontos de montagem compartilhados por meio das saídas dos comandos “df -h” e “mount”. Abaixo trago um exemplo da saída de outro comando útil que pode ser utilizado no cliente para descobrir quais diretórios estão sendo compartilhados pelo servidor:

showmount -e 192.168.1.101
Export list for 192.168.1.101:
/nfs/privado 192.168.1.100
/nfs/publico 192.168.1.0/24,192.168.1.100


  • showmount -e - Mostra lista de informações ‘-e de exports’ sobre servidores NFS montados.

Uma alternativa ao processo manual de configuração dos pontos de montagem compartilhados nos clientes é alterar o arquivo de configuração “/etc/fstab” para que as montagens sejam realizadas durante o boot. Para exemplificar esse processo em relação ao diretório público que criamos anteriormente, podemos incluir a linha abaixo ao final desse arquivo:

192.168.1.101:/nfs/publico  /mnt/publico   nfs   defaults   0   0

NIS

NIS ou melhor, Network Information Service (Serviço de Informações de Rede) é um protocolo de serviço de diretório cliente-servidor para distribuição de dados de configuração de sistema como nomes de usuário e de hospedeiro entre computadores em uma rede de computadores. Foi desenvolvido pela igualmente pela Sun Microsystems para facilitar a administração, configuração e manutenção de redes Unix-like juntamente com o NFS.

Este faz uso de um repositório central, NIS server, ou seja, uma base de dados centralizada na rede que agrega os arquivos de configuração necessários para realizar a manutenção em um host Unix.

O protocolo é baseado em Chamadas de Procedimento Remoto - RPC que utilizam um padrão de representação de dados externo. Em seu funcionamento há três tipos de ambientes NIS: master servers, slave servers e clients.

O servidores concentram as informações do repositório para dos hosts. Os master servers possuem uma cópia do repositório, enquanto os slave servers armazenam um espelhamento das informações de forma a garantir redundância e disponibilidade das informações em caso de falha dos servidores master. Já os clients acessam e fazem uso das informações disponibilizadas pelos servidores.

Instalando o servidor NIS

Agora vamos instalar o servidor e client NIS:

apt-get install -y nis

Preste atenção quando for pedido o NIS domain e coloque o domínio que você definio para seu servidor em /etc/resolv.conf. Caso não tenha definido nada, configure como localhost mesmo. Agora vamos configurar o /etc/default/nis:

Em vim /etc/default/nis:

# Em NISSERVER = adicione master.
NISSERVER=master

Em vim /etc/ypserv.securenets comente a seguinte linha:

# Essa linha dá acesso a todos, então comente ela
# 0.0.0.0 0.0.0.0 

# Adicione a máscara e range do seu ip para acesso
255.255.255.0	192.168.1.0

Agora vamos para o vim /var/yp/Makefile:

# Em MERGE_PASSWD modifique para:
MERGE_PASSWD=true

# O mesmo para MERGE_GROUP:
MERGE_GROUP=true

Configure corretamente o seu /etc/hosts com seu ip e domínio local. Por exemplo:

127.0.0.1       localhost
# Adicione o ip NIS e domínio
192.168.1.102       debian.seudominio.com.br        debian

Atualize a base de dados do NIS:

/usr/lib/yp/ypinit -m

Reinicie o NIS:

/etc/init.d/nis restart 

Agora aplique o banco de dados do NIS em seu usuário local:

cd /var/yp
make

Por fim, verifique em /var/log se ocorreu algo errado neste processo.


Instalando o client NIS

Vamos configurar o client NIS:

vim /etc/yp.conf:

# Edite as seguintes linhas:
# ypserver ypserver.network.com
# add to the end: [domain name] [server] [NIS server's hostname] 
domain seudominio.com.br debian.seudominio.com.br

Em seguida o /etc/nsswitch.conf adicione ou edite as seguintes linhas (caso já existam):

passwd: compat nis 
group: compat nis 
shadow: compat nis 
hosts: files dns nis 

Crie o diretório vim /etc/pam.d/common-session caso não exista:

session optional        pam_mkhomedir.so skel=/etc/skel umask=077

Reinicie o nis:

/etc/init.d/nis restart

Segurança de rede NFS

A simplicidade e a transparência fornecida pelo NFS e NIS devem ser pesados quando o assunto é segurança principalmente quando há transporte de dados confidenciais ou proprietários. Como por exemplo, as precauções para impedir o acesso não autorizado a uma máquina são medidas de segurança que são sempre bem vindas quando se trata de segurança de dados.

Para impor restrições de acesso, é recomendável antes verificar a senha dos usuários, documentar muito bem para não ter problemas futuros assim eliminando alguns usuários desnecessários para haver maior transparência de rede fornecida pelo NIS.

Nota: Neste artigo irei explicar apenas as medidas mais básicas para a segurança do servidor NFS/NIS. Se quiser aprofundar sobre segurança da informação em sistemas e servidores, recomendo a leitura da obra Pratical Unix & Internet Security.

O portmapper

Portmap é um servidor que converte números de programas RPC em números de portas DARPA. Ele deve estar em execução, a fim de fazer chamadas RPC como é o caso do NFS/NIS que usa ele. O portmapper mantém uma lista de quais os serviços que estão sendo executados em quais portas. Esta lista é usada por uma máquina de ligação para ver o que os portos que quer falar para aceder a determinados serviços. Para lidar com o portmap, iremos editar basicamente dois arquivos. São eles:

Nota: Os serviços RPC se registram em um diretório conhecido como portmapper. Um cliente querendo realizar uma consulta NFS primeiro consulta o portmapper (na porta 111, seja TCP ou UDP), e pergunta pelo servidor NFS; a resposta gralmente vem pela porta 2049 (a padrão para o NFS). Nem todos os serviços RPC necessariamente usam uma porta fixa.

  • /etc/hosts.allow - O arquivo /etc/hosts.allow é um arquivo de configuração do programa tcpd. O arquivo hosts.allow contém regras descrevendo que hosts tem permissão de acessar um serviço em sua máquina.
  • /etc/hosts.deny - O arquivo /etc/hosts.deny é um arquivo de configuração das regras descrevendo quais computadores não tem a permissão de acessar um serviço em sua máquina.

Estando claro do que se trata ambos os arquivos, vamos editar primeiro o /etc/hosts.deny com a seguinte linha:

portmap: ALL

Esta linha irá negar acesso a todos. Verifique se o seu portmapper está obedecendo a esta configuração através do seguinte comando:

rpcinfo -p
  • rpcinfo -p - Informa sobre a chamada de procedimento remoto RPC. O parâmetro -p é para apontar o host e se estiver vazio (como em nosso caso), aponta automaticamente para o localhost. Em nosso caso, este comando deve retornar valor algum ou um erro.

Agora vamos ao /etc/hosts.allow que deve lidar com todas as máquinas que devem ter acesso ao seu portmapper. Vamos supor que o endereço da sua máquina é 192.168.1.2100 e que vive na sub-rede 192.168.1.0/24 então, vamos escrever o seguinte no /etc/hosts.allow :

portmap: 192.168.1.100/24

Nota: Se você não tem certeza de qual o IP de sua rede e máscara, você pode usar o comando ifconfig para verificar o IP e máscara de rede. Caso ainda sim não saiba, poderá editar isso através do comando netstat ou através da interface de rede em /etc/network/interface .

Se você não usa recursos de segurança baseados no Kerberos, é vital garantir que apenas máquinas com permissão de usar o NFS possam se conectar nos vários servidores RPC requeridos, porque o protocolo básico confia nos dados recebidos a partir da rede. O firewall tem também que bloquear IP spoofing para prevenir que uma máquina de fora atue como uma de dentro e acesse às portas apropriadas tem que ser restrito às máquinas destinadas a acessar os compartilhamentos NFS.

Para permitir o acesso através de um firewall, as portas TCP e UDP 111, 2049 e 20048 precisam ser abertas quando for usado a configuração padrão; Usa-se o comando rpcinfo -p para examinar as portas exatas em uso no servidor. Para configurar o Firewall do servidor com iptables, usaremos os comandos a seguir:

iptables -A INPUT -p tcp -m tcp --dport 111 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 2049 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 20048 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 111 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 2049 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 20048 -j ACCEPT

Nota: Os comandos a cima podem ser salvos através do comando iptables-save > /etc/iptables/iptables.rules. Desta forma, caso o servidor seja reiniciado, não perderemos as regras de firewall. Para restaurar as regras, basta efetuar o caminho inverso. Isto é, iptables-restore < /etc/iptables/iptables.rules.

Versões mais antigas do protocolo necessitavam de outros serviços RPC que usavam portas dinamicamente atribuídas. Felizmente, com a versão 4 do NFS, apenas a porta 2049 (para NFS) e 111 (para o portmapper) são necessárias, e assim, fácil de configurar no firewall.


Ferramentas de diagnostico da rede NFS

Neste capítulo, apresentarei ferramentas para analisar a configuração e o desempenho do servidor NFS, ferramentas que monitoram o tráfego da rede NFS e ferramentas que fornecem várias estatísticas sobre o cliente e servidor NFS. São elas:

  • nfsstat -c - Exibe as estatísticas de cliente enquanto nfsstat -s mostra os totais de servidores. Sem argumentos, nfsstat imprime os dois conjuntos de dados estatísticosi.
  • snoop - Este programa pode monitorar, analisar, depurar, descarregar ou visualizar informações de fluxos DVB/MPEG/DSM-CC/ etc…
  • nfswatch - Ferramenta de monitorização de tráfego NFS. Ele pode capturar e analisar os pacotes NFS em uma interface de rede particular ou em todas as interfaces.
  • satan - Satan ou melhor (Security Administrator Tool for Analyzing Networks) é uma ferramenta para ajudar os administradores de sistemas. Ele reconhece vários problemas de segurança relacionados com a rede comuns, e relata os problemas sem realmente explorá-los. O Satan não vem por padrão. Mas pode ser encontrada aqui: www.fish2.com/satan/.

Nota: Todas as ferramentas a cima com exceção do Satan, vem por padrão no Debian 6,7, e 8 bem como em sistemas baseados em RedHat como Fedora, CentOS e Rhel.

Outro ponto importante sobre monitoramento além das ferramentas citadas a cima, é conhecer o caminho e como funciona o mecanismo de verificação de logs para o servidor NFS como descrito a baixo:

  • /etc/nfs/nfslog.conf - Configuração de log.
  • /etc/default/nfslogd - Configuração do do nfslogd.
  • /etc/nfs/nfslogtab - Informação sobre a localização dos arquivos de buffer.
  • /var/nfs/nfslog - Registro de transação de logs.
  • /var/nfs/nfslog_workbuffer - Ações do RPC que são gravados pelo kernel e por ações do nfslogd.

Debugando problemas da rede NFS

Durante a depuração de um problema de rede, é investigar sobre a possível causa do problema, e então começar filtrar os fatores e excluir possibilidades. Por exemplo, se suas tentativas para ligar a um servidor de NIS está falhando, você pode fazer um teste de ping, usar recursos como rpcinfo, entre outros fatores.

Vamos supor então que nossa conecxão com o NIS e NFS esteja com problema. Irei apontar alguns caminhos para percorrer-mos de modo que lhe ajude a resolver a questão. São eles:

Resposta de ARP duplicadas

Address Resolution Protocol ou ARP é um protocolo usado para encontrar um endereço da camada de ligação de dados (Ethernet, por exemplo) a partir do endereço da camada de rede (como um endereço IP). O emissor difunde em broadcast um pacote ARP contendo o endereço IP de outro host e espera uma resposta com um endereço MAC respectivo.

Cada máquina mantém uma tabela de resolução em cache para reduzir a latência e carga na rede. O ARP permite que o endereço IP seja independente do endereço Ethernet, mas apenas funciona se todos os hosts o suportarem. Digite man arp e leia a manpage deste protocolo.

Geralmente quando o problema é este, o servidor costuma cair por vários minutos e o client começa a transmitir mensagens tais como:

NFS server host not responding still trying


ou

ypbind: NIS server not responding for domain "lobocode"; still trying


Para testar se o problema é este, teremos que remover o servidor da tabela ARP e testar no cliente afim de rastrear o problema. Consulte como manipular a tabela ARPna manpage ou no site do xmodulo.com.

Servidor NIS renegado

Um usuário na nossa rede informou que ele não conseguia entrar em sua área de trabalho. Ele forneceu seu nome de usuário e a mesma senha que ele estava usando nos últimos seis meses, e sempre foi-lhe dito “Login incorreto.” Para a frustração, ele reiniciou sua máquina. Ao tentar montar NFS filesystems, a estação de trabalho não foi capaz de encontrar qualquer um dos hosts do servidor NFS no NIS map e ainda gerou erros de mapa, tal como:

nfs mount: host: : RPC: Unknown host


Aparentemente o problema parecia ser com o próprio NIS. Meu palpite é que tratava-se de uma máquina disfarçada como um servidor NIS válido, ou que era um servidor de NIS cujos mapas tinham sido destruídos. Porque ninguém pode fazer logon na máquina, afinal defini o serviço como usuário único. De todo modo, resolvi fazer uns testes manuais afim de averiguar onde o NIS está vinculado:

Iniciei então o serviço inetinit:

/etc/init.d/networking start

E retornou:

NIS domainname is nesales
Starting IPv4 router discovery.
Starting IPv6 neighbor discovery.
Setting default IPv6 interface for multicast: add net ff00::/8: gateway
fe80::a00:20ff:fea0:3390


Em seguida o rpcinfo:

/etc/init.d/rpcbind start

Que obterá a saída:

starting rpc services: rpcbind keyserv ypbind done.


Por fim, o ypwhich:

ypwhich

Que obterá a saída:

131.40.52.25


  • ypwhich - ypwhich retorna o nome do servidor NIS que fornece os serviços NIS para um cliente NIS. Se chamado sem argumentos, ele retorna o NIS da máquina local. Se o nome do host for especificado, essa máquina é consultada para saber quais serviços NIS ele está usando.

Usei manualmente o script de inicialização de /etc/init.d/networking para inicializar o nome de domínio e configurar o roteamento. Então, invoquei o script /etc/init.d/rpcbind para iniciar o ypbind. Por fim, observe que ypwhich não foi capaz de igualar o endereço IP do servidor NIS no mapa NIS de hosts, por este motivo ele retornou o endereço IP. O endereço IP pertence a uma máquina que não era para ser um servidor NIS. Então encontramos a origem do problema.

Alternativa

Uma possível alternativa ao NFS seria o projeto GlusterFS pois trata-se de um sistema cujo principal objetivo é a escalabilidade, sendo que para isso seus projetistas utilizaram conceitos da computação de alto desempenho, como a agregação. Este sistema pode executar sobre diversos sistemas operacionais, como GNU/Linux, FreeBSD, OpenSolaris e Mac OS X. Saiba mais sobre esta alternativa na página da documentação oficial do Gluterfs.

Referencias

Pratical Unix & Internet Security

Managing NFS and NIS, 2nd Edition

Configuring secure Network File Systemi - IBM

IBM - NFS intro

Network share performance differences between nfs smb
blog comments powered by Disqus