Astra linux nfs настройка

Linux NFS Server: How to Set Up Server and Client

Network File Sharing (NFS) is a protocol that allows you to share directories and files with other Linux clients over a network. Shared directories are typically created on a file server, running the NFS server component. Users add files to them, which are then shared with other users who have access to the folder.

An NFS file share is mounted on a client machine, making it available just like folders the user created locally. NFS is particularly useful when disk space is limited and you need to exchange public data between client computers.

This is part of our series of articles about Linux on Azure.

In this article, you will learn:

Quick Tutorial #1: Setting Up an NFS Server with an NFS Share

Let’s see how to set up an NFS server and create an NFS file share, which client machines can mount and access.

Installing NFS Server

Here is how to install the NFS Kernel—this is the server component that enables a machine to expose directories as NFS shares.

sudo apt-get update
sudo apt install nfs-kernel-server

yum -y install nfs-utils
apt-get install nfs-kernel-server

Create Root NFS Directory

We’ll now create the root directory of the NFS shares, this is also known as an export folder.

sudo mkdir /mnt/myshareddir

Set permissions so that any user on the client machine can access the folder (in the real world you need to consider if the folder needs more restrictive settings).

sudo chown nobody:nogroup /mnt/myshareddir #no-one is owner
sudo chmod 777 /mnt/myshareddir #everyone can modify files

Define Access for NFS Clients in Export File

To grant access to NFS clients, we’ll need to define an export file. The file is typically located at /etc/exports

Edit the /etc/exports file in a text editor, and add one of the following three directives.

All the directives below use the options rw , which enables both read and write, sync , which writes changes to disk before allowing users to access the modified file, and no_subtree_check , which means NFS doesn’t check if each subdirectory is accessible to the user.

To enable access to a single client

To enable access to several clients

To enable access to an entire subnet

Make the NFS Share Available to Clients

You can now make the shared directory available to clients using the exportfs command. After running this command, the NFS Kernel should be restarted.

sudo exportfs -a #making the file share available
sudo systemctl restart nfs-kernel-server #restarting the NFS kernel

If you have a firewall enabled, you’ll also need to open up firewall access using the sudo ufw allow command.

Quick Tutorial #2: Setting Up NFS on Client Machine and Mounting an NFS Share

Now that we have set up the NFS server, let’s see how to share a folder, defined as an NFS share, with a Linux computer by mounting it on the local machine.

Installing NFS Client Packages

Here are the packages you need to install to enable mounting an NFS share on a local Linux machine.

sudo apt update
sudo apt install nfs-common

sudo yum install nfs-utils

Mounting the NFS File Share Temporarily

You can mount the NFS folder to a specific location on the local machine, known as a mount point, using the following commands.

1. Create a local directory—this will be the mount point for the NFS share. In our example we’ll call the folder /var/locally-mounted.

1. Mount the file share by running the mount command, as follows. There is no output if the command is successful.

sudo mount -t nfs 192.168.20.100:/myshareddir /var/locally-mounted

The mount point now becomes the root of the mounted file share, and under it you should find all the subdirectories stored in the NFS file share on the server.

Mounting NFS File Shares Permanently

Remote NFS directories can be automatically mounted when the local system is started. You can define this in the /etc/fstab file. In order to ensure an NFS file share is mounted locally on startup, you need to add a line to this file with the relevant file share details.

To automatically mount NFS shares on Linux, do the following:

1. Create a local directory that will be used to mount the file share.

1. Edit the /etc/fstab file using the nano command or any text editor.
2. Add a line defining the NFS share. Insert a tab character between each parameter. It should appear as one line with no line breaks.

The last three parameters indicate NFS options (which we set to default), dumping of file system and filesystem check (these are typically not used so we set them to 0).

1. Now mount the file share using the following command. The next time the system starts, the folder will be mounted automatically.

Azure NetApp Files: A Cloud-Based NFS Server Replacement

Microsoft Azure, a popular public cloud service, lets you set up NFS file shares in the cloud and access them from machines in your local data center, or deployed in the Azure cloud.

Azure NetApp Files is a cloud service offering enterprise-class, high-performance file storage for enterprises. It supports NFS versions 3.1 and onwards.

Azure NetApp Files supports all types of production workloads and provides built-in high availability. You can choose the level and performance of the service, and perform instant snapshots of your data.

Extreme File Performance

Leverage industry-leading NetApp technology to migrate the most demanding Linux and Windows file workloads to Azure. Azure NetApp Files delivers sub-millisecond latency and equivalent performance to what you would achieve with a local bare metal server.

Azure NetApp Files provides three performance levels: Standard, Premium, and Ultra. You can provision file shares in any of the tiers with one click.

Integrated Data Management

Azure NetApp Files integrates with complex business workloads such as SAP HANA, high performance computing (HPC), line of business (LOB) applications, and virtual desktop infrastructure (VDI). For these and many more enterprise workloads, it offers integrated data management and application awareness for backups and snapshots.

Central Management

You can manage file shares using Azure Portal or CLI, PowerShell commands, or a REST API, just like any other Azure service. Azure NetApp Files supports multiple storage protocols in one service, including NFSv3, SMB3.1.x, and NFSv4.1. This allows you to transition workloads to the cloud in a “lift and shift” model, without requiring code changes.

Migrate with Confidence

When migrating large enterprise workloads, rsync data transfer is not enough. With Azure NetApp Files you can manage large-scale data transfer and synchronization at ease.

The service provides FIPS 140-2-compliant data encryption, role-based access control (RBAC), Active Directory authentication, and access control lists (ACL). Azure NetApp Files complies with major industry certifications such as HIPAA, SOC and GDPR. These and other enterprise-grade features mean you can migrate any enterprise workload to the cloud with complete confidence.

Источник

Сетевая файловая система NFS с аутентификацией Kerberos в домене FreeIPA

«В случае необходимости использования мандатного управления доступом на сетевых дисках, их монтирование в файловую систему ОС должно осуществляться только с использованием файловой системы CIFS, поддерживающей расширенные (в т.ч. мандатные) атрибуты пользователей;»

«Руководство по КСЗ. Часть 1 РУСБ.10015-01 97 01-1» п. 17.3. «Условия применения»

При настройках по умолчанию аутентификация через Kerberos в файловой системе NFS осуществляется:

Таким образом, монтирование сетевого ресурса NFS может быть выполнено любым пользователем или процессом. С одной стороны, это позволяет автоматически монтировать общие разделяемые ресурсы до входа первого пользователя, но, с другой стороны, может стать причиной утечки или повреждения данных при некорректно настроенных правах доступа.

В статье рассматривается использование NFSv4. Более старые версии использовать не рекомендуется, так как они подвержены известным уязвимостям и некорректно работают при использовании аутентификации Kerberos.

При некорректно настроенных параметрах подключения NFS может выполнять монтирование с произвольным понижением уровня протокола (NFSv3 вместо NFSv4) и/или изменением типа аутентификации (аутентификация SYS вместо Kerberos), что также является источником потенциальных уязвимостей.

Описание стенда

• контроллер домена FreeIPA:
  • имя сервера ipa0.ipadomain0.ru;
  • имя администратора admin;
  • IP-адрес контроллера домена не используется, так как подразумевается наличие настроенной службы DNS;
  • имя клиента host0.ipadomain0.ru;

  Настройка сервера

  sudo sed -i ‘s/^[[:space:]]*NEED_SVCGSSD[[:space:]]*=.*/NEED_SVCGSSD=»yes»/’ /etc/default/nfs-kernel-server sudo sed -i ‘s/^[[:space:]]*NEED_GSSD[[:space:]]*=.*/NEED_GSSD=yes/’ /etc/default/nfs-common
  sudo sed -i ‘s/^[[:space:]]*NEED_IDMAPD[[:space:]]*=.*/NEED_IDMAPD=yes/’ /etc/default/nfs-common

  Если билет Kerberos был получен до регистрации службы, то после регистрации службы он должен быть обновлен (получен повторно).

  ldapmodify -x -D «cn=directory manager» -W -h ipa0.ipadomain0.ru << EOT
  dn: cn=IPADOMAIN0.RU,cn=kerberos,dc=ipadomain0,dc=ru
  changetype: modify
  add: krbSupportedEncSaltTypes
  krbSupportedEncSaltTypes: des-cbc-crc:normal
  EOT
  ldapmodify -x -D «cn=directory manager» -W -h ipa0.ipadomain0.ru << EOT
  dn: cn=IPADOMAIN0.RU,cn=kerberos,dc=ipadomain0,dc=ru
  add: krbSupportedEncSaltTypes
  krbSupportedEncSaltTypes: des-cbc-crc:special
  EOT
  ldapmodify -x -D «cn=directory manager» -W -h ipa0.ipadomain0.ru << EOT
  dn: cn=IPADOMAIN0.RU,cn=kerberos,dc=ipadomain0,dc=ru
  add: krbDefaultEncSaltTypes
  krbDefaultEncSaltTypes: des-cbc-crc:special
  EOT

  Разделяемые ресурсы определяются в конфигурационном файле /etc/exports. Подробно про возможные параметры разделяемых ресурсов см. man exports.

  В NFSv4 все сетевые ресурсы предоставлены единым деревом каталогов. Соответственно, в списке разделяемых ресурсов один из них должен быть обозначен как корневой. Для этого используется параметр fsid=0. Отсутствие или некорректное определение корневого ресурса ведёт к неработоспособности примонтированных ресурсов, и, в случае монтирования домашних каталогов, к невозможности входа пользователей.

  Пример файла с ресурсами (экспортируется домашний ката/etлог пользователей /home и созданный каталог /export):

  / *(rw,fsid=0,no_subtree_check,sec=krb5:krb5i:krb5p) /home gss/krb5i(rw,sync,no_subtree_check) /export *(rw,sync,no_subtree_check,no_root_squash,sec=krb5:krb5i:krb5p)

  В приведенном примере первый ресурс — корневой, и использованы два альтернативных синтаксиса для «подчинённых» ресурсов NFSv4 с аутентификацией Kerberos.
  В целях обеспечения безопасности в разделяемых ресурсах используется технология подмены идентификатора суперпользователя (root_squash). При этом операции, инициированные суперпользователем, выполняются от имени nobody:nogroup или от имени Kerberos-пользователя (См. ниже Настройка клиентской аутентификации Kerberos). Об этом ограничении следует помнить планируя настройку прав доступа в разделяемых ресурсах.

  Для того, чтобы в «подчиненные» ресурсы была разрешена запись, запись должна быть разрешена в корневой ресурс.
  Для того, чтобы при доступе к «подчиненным» ресурсам корректно работала аутентификация Kerberos, корневой ресурс должен использовать такой же тип аутентификации.
  Параметр no_root_squash неработоспособен, то есть подмена идентификатора суперпользователя выполняется всегда. См. ниже Настройка клиентской аутентификации Kerberos.

  Источник