From Mageia wiki
Jump to: navigation, search


THIS PAGE IS A DRAFT

It requires improvements. If you want to improve it, simply log in and click on the Edit tab.

Please remove this {{Draft}} template, when you're sure the page is complete and correct.

Outline

An NAS (Network Attached Storage) server can be an excellent addition to the infrastructure of small networks with machines that run different OSes, and where users want to co-operate and share data regardless of the specific OS platform they are using. Users of the data on the NAS can access this data just like local data on their machine.

I am using such a server on my home network, and the experience is excellent. The server is part of my Fritz!Box 7590 router (but there is nothing specific to this machine - there exists quite a choice of similar equipment). However, the simple connection of a particular client machine to a local network that has an NAS server is not sufficient for giving users access to the NAS - the client must be configured for the communication with the NAS. That requires some simple actions when a Linux machine is configured:

  • although these actions are quite simple, they are not evident and are not well documented,
  • the particular implementation of NAS on servers like Fritzbox routers uses the "Samba" protocol, which raises some security issues that need to be considered.

The present wiki-page is meant as documentation for owners of machines to be connected to a NAS service, helping them to rapidly and easily get started. I hope that it also helps to increase awareness about the existence of this nice tool.

Background

The communication between the partners that communicate in an NAS requires a common protocol ("NFS" or "Samba") to be respected for the exchange of user data. The choice of a protocol is normally imposed by the manufacturer of the NAS server - i.e. the "Samba" protocol in the case of the Fritzbox (and many other makes of servers). This article is about the "Samba" protocol, respectively how it is deployed and configured in a Linux environment.

"Server Message Block" (SMB) - has been developed in the early 1990s as a protocol that defines a set of rules for the exchange of files and data between a server and clients. The term of Samba had, initially, been the name of a project for developing corresponding free software.

Today, the term "Samba" is generally used for the protocol itself and the software implementing that protocol. Samba is still actively maintained, with the principal versions being Samba 1, 2 and 3, each of them with sub-versions. The most important currently used version is Samba 3.1.1; the initial version (Samba 1.0) is also known as CIFS ("Common Internet File System"); CIFS is still the only protocol available on many NAS servers.

The protocol and corresponding implementations were initially intended for the dialog between machines using DOS and SunOS as their operating system. Very rapidly, the implementations of Samba were then ported to Linux. Today, practically all Linux distributions provide Samba as an integral part of their standard set of software.

For MS Windows, Samba has become a key element for the support of data sharing between Windows machines over the network - Microsoft became the most important actor in the development of Samba. CIFS is no longer activated by default in Windows-10, but it can be activated as an explicitly specified option when a Windows system is installed.

The concept of an NAS server

The fundamental constituents of an NAS system are:

  • the support and accessibility of shared data on the file system of the NAS server,
  • the implementation of client software on participating client machines that exchange data with the server,
  • the common respect of a communication protocol by all partners,
  • where that data appears like local data of the client machines,
  • and several client machines have concurrent access to data on the server.

This concept also determines how the structure of files from the server is represented on a client: the root of a tree of files on the server is attached to an empty directory on the client - therefore the files from the server look like a sub-structure of the client's file-structure. The notion of ownership and access rights - well known to Linux users - is not part of the original concept.

Practically, the implementation of NAS software on the client needs to:

  1. intercept the I/O requests on the client machines, made by users - and OS-programs - at a high level of abstraction,
  2. substitute these requests by calls to the corresponding procedures provided by the operating system, respectively its interface to the internet.

In general, an NAS server comes as an independent system, connected to the network, and equipped with a substantial amount of storage (on the FritzBox, the user is meant to provide his own storage in the form of USB storage plugged into a USB plug on the FritzBox). Standalone NAS servers can be bought for, typically, some 200 Euros.

The implementation of FritzNas is a particular case, easy to put in place: the service is some kind of "wart" on the FritzBox that primarily has the role of an internet router and modem connection.

The discussion in this document assumes a FritzNas server to be used - but the document contains practically nothing that does not also apply to any standalone NAS Server. In fact, the term "NAS system" is used wherever - to be precise - FritzNas would be the correct term.

Up until recently, the use of CIFS has been a choice imposed by the manufacturer of the FritzBox - just like the choice made by many other providers of stand-alone NAS servers. CIFS is certainly "old" software, but it runs smoothly and is still very popular. At present, there is a move to the use of newer versions of Samba. MS Windows, for instance, retired CIFS to the status of a normally inactive feature that - if needed - must be explicitly activated.

Security, protection of shared data

CIFS and WannaCry

CIFS (Samba version 1.0) has been the vector for the WannaCry ransomeware attack. Although Microsoft patched this problem very rapidly, CIFS has retained a stigma vulnerability and of lacking security.

For a very long period, CIFS has remained the principal choice for the protocol used by providers of NAS servers, and no other similar attacks are known. This particular security problem does not seem to be a serious threat anymore, particularly for NAS environments that are run behind a router that provides a firewall and uses Network Address Translation.

The far more serious topic for security concerns is the lack of protection against misuse within a local network, based on the lack of user-specific access control.

Access to local data

Samba had originally been developed for handling data in the context of Microsoft Windows systems; correspondingly, it does not know how to handle ownership and access rights.

This represents a severe drawback with respect to what users of a Linux system are used to have, and what they expect as substantial for the security of their data: seen from a Linux system, all files and directories residing on the NAS server belong to root and have read and write permission.

For more information on security mechanisms and for potential concepts for working around this problem, see, for instance,

Target readers of this wiki page

This wiki page documents how such an NAS environment can be created on a Mageia system: it focuses primarily on issues relative to the configuration of client software on machines that use Mageia. In this respect, Mageia is not much different from other distributions, and this document can probably be helpful if another Linux distribution is used. Finally, a short summary outlines how Samba client software can be made to work on a Windows-10 machine.

The presentation of this page is tailored for the owner of a Linux machine, a non-specialist who is capable to select and install packages, and knows to do simple command-line operations, possibly using sudo.

The arrangement of text into paragraphs should facilitate jumping across sections of text that are of no particular interest to a given reader.

Configuring a Samba client on Mageia

Packages required

The packages needed for running a Samba client on Mageia are part of the standard distribution. Samba version 1.0 (CIFS) is a particular case: an additional package "cifs-utils" must be installed - for a command-line install, simply do

urpmi cifs-utils

This package is available in practically all distros. Please note that its name may be misleading - this package supports the entire range of Samba versions, not only version 1.0.

Installing the package creates some files that are of interest in the context of this document:

Local documentation on Samba

If you install "cifs-utils", you also obtain a set of man-pages. The only one that is of interest here is the page mount.cifs (8): it describes some specific aspects for mounting a Samba file-system (but this turns out to be not very helpful for the issues that need to be resolved when configuring the details for mounting a Samba partition).

To find the names of the remainder of these man-pages, you can use the "Mageia Control Center", resp. its "Install and Remove Software" Section: find and select "cifs-utils" and hit the Files button. In the same way you can also find the name of local documentation files that are available at /usr/share/doc/cifs-utils.

Please note: presently the files with Samba man-pages cannot be displayed with tools that use man2html to convert the contents of the <page_name>.xz file into an HTML file.

The Samba configuration file

The file /etc/samba/smb.conf is the configuration file for the Linux client. This file is, at it is installed, OK for running a client NAS.

Automatically mounting the NAS file-system

Naïvely, one would expect that a properly formatted line in /etc/fstab is all that is needed to get the files that reside on the NAS server automatically mounted when the client system boots. But Linux has a nasty snare: /etc/fstab is processed quite early in the sequence of actions that happen when the system starts - before Samba has been fully launched. As a consequence, the system does not manage to mount files from a Samba server when it boots. Moreover, Linux will realize that the directory specified in /etc/fstab still needs mounting and will, therefore, launch a "start process" that waits for the remote files to be mounted. The initialization will be suspended until the start process times out after several minutes.

Alternatives for a workaround

Several possibilities exist to deal with this situation - and with a similar situation the arrives when the system is not connected to the network when it boots:

  • Refrain from using the automount mechanism foreseen for directories that figure in /etc/fstab:
  1. as root, manually mount the directory from a command-line,
  2. or, provide a script to be executed towards the end of system initialization when Samba is up and running.
  • Use the mechanism discussed in the next paragraph ("recommended approach").

Recommended approach

There exists a simple alternative (see https://askubuntu.com/questions/1081601/how-to-fix-fstab-samba-mounts-not-loading): it exploits the fact that the directory /etc/sysconfig/network-scripts/ifup.d/ is a special directory: executable files in that directory will be submitted for execution just after the filesystem has become fully operational - precisely what is needed for the delayed mounting an NAS file-system (on other distros - e.g. Ubuntu -, this directory is located at /etc/network/if-up.d/).

You can use this feature by creating a 2-line file (owned by root, with permissions 0755) with the contents (where <samba-root> stands for the mount-point of the NAS-partition; the name of the file is immaterial - as long as the file is a pending node under if-up.d)

#!bin/sh
mount <samba-root>

Specifying the remote directory in /etc/fstab

Even if an automatic mount at boot-time is not required, it is recommended to provide a line in /etc/fstab that specifies the mount options. A manual mount can then be launched simply by saying "mount <samba_root>" (<samba_root> meaning, as above, the name of the directory node where the samba partition is mounted - /fritzbox in the following example) .

For an automatic mount, applying the concepts discussed above, the following line in /etc/fstab works correctly (the following examples are valid for mounting a Samba-1 partition, mounting Samba-3 partitions is discussed farther down):

//192.168.0.1/fritz.nas /fritzbox cifs credentials=/etc/samba/smbcredentials,noserverino,noauto,defaults,vers=1.0 0 0

Essentially, this line corresponds to a command-line mount as documented in the "mount 8" man-page. Many of the options that are used have already been discussed. Here are some additional comments:

The leading three fields, in turn, specify

  1. the address of the NAS server (its IP address and the name of the service at this address - in Samba terminology: the Samba share ),
  2. the mount-point of the samba partition specifies the root of the directory-tree to be mounted from the samba server (before mounting a void directory),
  3. the type of the file-system to be mounted - cifs for mounting an NAS partition; (recently the type smb3 has been added to the types handled by Linux "mount", but only cifs mounts the NAS partition as it is documented here) .

Please note that the use of the symbol cifs for the specification of the type is, in this context, not specific to Samba version 1 - the version to be respected when Samba operates depends on what is specified in the vers field

This is followed by a list of comma-separated options to be applied when the file-system is mounted (the sequence of the options is immaterial):

  • credentials ... specifies a file that contains user names and passwords; this information is used by Samba to verify if the user is authorized to have access (the man-page also illustrates how this information could be provided directly in /etc/fstab; but it would be foolish to include this information in a file with public read access (Linux requires /etc/fstab to permit public read access); for the contents of the credentials file (owned by root, permissions 0600), use
username=<name of the user>
password=<his password>

no convention exists for the name of that file, or where it should be placed - /etc/smbcredentials is an arbitrary choice - but the file must be read-protected; permissions of 0600 are OK;

  • vers = ... specifies the version of the Samba protocol for which this line is coded,
  • noserverino indicates that the client (your machine) will generate inode numbers itself, rather than using the actual ones from the server;
  • noauto: inhibits "mount" to automatically trigger an immediate mount when the system is initialized; this is important to allow the network to be initialized before the NAS partition is mounted, and it allows to let the system be used without a connection to the network (laptops !);
  • defaults: this is a shortcut recognized by mount and understood as a list of frequently specified options: rw, suid, dev, exec, auto, nouser, async.

The final two numeric fields are fstab boiler-plate, they determine dumping-control and file-system checking - see the man-page for fstab.

Command-line mount with explicit specification of mount options

It may be convenient (for debugging, for instance) to manually mount the Samba partition with particular mount options, but without modifying /etc/fstab. The following line is an example how this can be done:

sudo mount -t cifs -o credentials=/etc/samba/smbcredentials,noserverino,noauto,defaults,vers=1.0
//192.168.0.1/fritz.nas /fritzbox 

Submitting this as a command-line has the same effect as doing a mount that retrieves the options from the line in /etc/fstab discussed at the top of this Section.

Mounting a partition for access with Samba 3

NAS equipment that uses Samba-3 will increasingly replace equipment that runs Samba-1. Samba-3 offers, with respect to Samba-1, the following principal advantages:

  • the software for Samba-3 is recent and kept up-to-date, it offers more flexibility and new features;
  • there is no need for the client to hardwire a specific version of the Samba protocol into the mount options: the server negotiates with the client and determines the highest possible level of the protocol that can be run;
  • nevertheless, it is regrettable that the implementation of Samba-3 has been made without improving the error messages issued - since Samba-3 is more complex, this issue has become even more annoying than with Samba-1.

With respect to the discussion on mounting a Samba-1 partition, some small differences in the contents of the /etc/fstab entry, resp. the command line for mounting the samba partition must be observed:

  • the term vers=<samba-version-number> needs to be eliminated from the option list (samba will automatically negotiate the version to be used),
  • add an option that specifies the name of the user who claims access to the samba partition (and requires authorization by the samba server): username=<user-name>,
  • the "rw" mount-option has no effect - therefore additional fields must be added to the option list in order to control the Unix permissions for the files in the samba partition when it is mounted (remember that, like Windows, samba does not support the notion of "permissions"); 2 alternatives have been verified to work correctly and permit to control whether the files in the partion are writeable or not - alone or in combination;
  1. specify the uid and gid of the user who will appear as the owner of (all!) files mounted with the cifs partition - add the following fields to the list of options: uid=<user-id>,gid=<group-id>,forceuid,forcegid - note that this is not necessarily the user specified in the "username" option for authorization by the samba server,
  2. specify the property mask of files mounted with the cifs partition: add one additional option file_mode=<octal-mask>.

Please, also note that the configuration file of Samba /etc/samba/smb.conf has no effect on how Samba proceeds with a cifs transfer.

As an example, here is the fstab entry I include for mounting the Samba-3 NAS drive of my Fritzbox 7590 router, resp. its NAS server (FritzBox routers require FritzOS version 7.20 and above for the support of Samba-3 - the 7590 was one of the first routers for which this had become available); for details, refer to the discussion on mounting Samba-1 paritions.

//192.168.0.1/FRITZ.NAS	/fritzbox cifs username=harms,credentials=/etc/samba/smbcredentials,noserverino,noauto,defaults,uid=1000,gid=1000,forceuid,forcegid 0 0

Mageia specificity

All the issues discussed in these paragraphs are common to most Linux distributions - very few topics are particular to Mageia. There may be differences in the arrangement of Samba software into specific packages, or in the file-system paths where support files are stored (for instance, the special directory /etc/sysconfig/network-scripts/ifup.d - see above - in Ubuntu is located at /etc/network/if-up.d/fstab.

Microsoft-Windows related issues

Configuring user access to the NAS service

There is very little to be done to get NAS access working on an MS Windows machine. The principal difficulty is to find where, and at a given moment in the evolution of the Windows documentation, the corresponding controls can be found.

The following paragraphs are not a full discussion, but simply provide a guide on how to undertake these steps.

Activating CIFS

This step is - evidently - only necessary if the NAS only supports Samba-1.

As already said, Samba version 1.0 is available on Windows-10 machines but is a "Feature" that needs to be explicitly activated as a first action. This can be done by proceeding as follows:

  1. hit the "Start" button (leftmost in task-bar) and type "Features",
  2. select "Turn Windows features on or off";
  3. in the list of features that are listed then, scroll down to the line for "SMB1.0 / CIFS File sharing support", and activate the corresponding check button.

That is all, the CIFS support is now activated.

Accessing data on NAS from the user file-system

By default, Windows-10 hides access to remote data (i.e. data supported on remote servers via network access). To "see" such data, the user must turn on "network discovery":

  1. launch the "Windows Control Center",
  2. open the "Network and Internet" tab,
  3. select "Network and Sharing Center",
  4. select "Change advanced sharing settings";
  5. you now see a radio-button labeled "Turn on network discovery" - activate this button.

A final step is necessary to integrate the directory tree that resides on the NAS into the directory tree of the user of the Windows machine - the equivalent of the "mount" operation on a Linux system.

With an NAS server that runs CIFS and the Windows-10 version available when this wiki page had been drafted 2 years ago, the procedure has been as follows:

  • go to the top-level directory page - "This PC (C)",
  • activate the "Network" tab,
  • under this tab, you will now find a tab labeled "FRITZ-NAS",
  • once you open that tab, you have access to the data on the NAS server and can use it like any local data.

If your NAS is capable of running Samba-3 and if your Windows system has been updated to the current level (1903, July 2020), proceed as follows

  1. go to the top-level directory page - "This PC (C)",
  2. hit the "Map a network device" tab,
  3. specify a "drive-letter", a letter for referring to the NAS partition that - so far - is not used for another partition,
  4. specify the name of the NAS device as configured in the Fritzbox
  • by doing: Home Network -> USB Devices -> Home Network Sharing -> Name,
  • or by using the pre-configured value "FRITZ.NAS",
  • but with the slashes replaced by back-slashes;

with the settings used in the Linux Section, this results in \\192.168.0.1\fritz.nas.

Conclusions

Installing a lightweight NAS server on a small network, possibly with different-OS machines, can be a powerfull extension of your network infrastructure:

  • it presents an alternative for supporting access to shared remote data without requiring access to a cloud service,
  • it can be obtained at quite moderate cost,
  • installation only requires a very limited investment in time,
  • it practically does not require any maintenance,
  • client machines running various OS platforms are supported (I have positive experience connecting Windows-10, Mageia-Linus, Raspberry-Pi machines, Mac-OS and Android machines should not present any problems).

However, the service of an NAS environment does not go beyond the level of the access to raw data. This is different from applications that offer distributed client-server implementations for specific tasks (but NAS could be used to implement such a service).

In some cases, NAS can help to fake the availability of a distributed service by making local applications exploit data that looks like local data but, in fact, is supported on the network. An example is the use of a Lightening calendar (realized as an add-on to Thunderbird): the calendar is conceived to work with local calendar files, but these files can be substitued / mixed with files that reside on an NAS.