3. page content

Continuation

The description on the first page we created a share with the Samba server installed on Linux, for which the second page We were connected from Windows.

On this page, we use sharing in the reverse direction: We use cifs-utils to connect to shared directories in Windows.

Accessing Windows Sharing from Linux

First, create or select a directory on the Windows machine that you want to share.

For the sake of simplicity, I created a directory called "Share" in the root directory of my C drive:

The next step on the Linux machine is to make sure that the hosts file contains the IP address of the Windows machine so that we can refer to it more conveniently, so it is advisable to set the machine's real name and IP address.

nano /etc/hosts

For me, it looks like this:

192.168.1.103   bnd-asztali-v

The description on the first page we installed the cifs-utils we will need it now. So, if you missed it, we'll make up for it:

apt-get install cifs-utils

On the Linux machine, look for a location where you will mount the shared Windows directory.

I create a directory for this purpose / Mnt under. Whether you create it as a user or as a root, it doesn't matter, because the system will set the directory owner when mount. However, a / Mnt only root has write access so root remains.

mkdir /mnt/asztali-megosztás

So for me this will be the attachment point.

Now, mount the above shared Windows directory as root. To do this, use the mount command:

mount -t cifs //bnd-asztali-v/Megosztás /mnt/asztali-megosztás/ -o user=botond,uid=botond,gid=botond,iocharset=utf8,sec=ntlm

The options given here have the following meanings:

• user: The username of the remote share (in this case, the Windows machine)
• uid: The name or UID of the local user. This user will own the attached directory.
• gid: The name or group ID of the local group. This group will be the owner of the linked directory
• iocharset: Character encoding of file structure names.
• sec: Encryption method. Ntlm is good for Windows shares.

You will then be prompted for the user's password and then the shared Windows directory will be available in the path specified at the mount point.

If you do not want to type your password later, you can also enter it at the command line:

mount -t cifs //<windows gépnév>/<megosztás> /<helyi csatolási pont> -o user=<megosztás felhasználóneve>,pass=<megosztás jelszava>,uid=<helyi felhasználó>,gid=<helyi csoport>,iocharset=utf8,sec=ntlm

It can also be used from scripts. However, this is not a safe solution if you enter passwords at the command line, especially if you put them in scripts afterwards. The solution to this is a credentials file.

Additional parameters and settings for cifs mount can be found in the mount.cifs manual side.

Use Credentials file for secure connection

You can connect to remote sharing more securely by not entering your access information on the command line, but instead storing it in a special file that you can then reference from the command line. This way, your passwords will not be visible anywhere.

The credentials file described here can be used for any password mount, not just for connecting to Windows shares.

In your Linux user account, to whom you want to mount the share, create a file, such as:

nano ~/.asztali-v-credentials

I create it as a hidden file, so it's even better. Then add the following:

username=<megosztás felhasználóneve>
password=<megosztás jelszava>
domain=<domain név>

Last of all, the domain can be omitted when working on a local network. Also, make sure there are no spaces, special characters, etc. at the end of the lines, as mount is sensitive to this.

Then save the file and set it with a secure permissions on the chmod command:

chmod go-r ~/.asztali-v-credentials

Here, we did so by removing the read access (-r) from group (g) and others (o). So the file is now read only by its host and root.

Then modify your mount command accordingly:

mount -t cifs //bnd-asztali-v/Megosztás /mnt/asztali-megosztás/ -o credentials=/home/botond/.asztali-v-vcredentials,uid=botond,gid=botond,iocharset=utf8,sec=ntlm

The uid = and gid = options still remain here because they set the local user as the owner of the share.

Thus, we protected our access data from being displayed in any command line or script.

Otherwise, this security solution is similar to that used with MySQL defaults files.

Make the connection last on Linux

You can also mount different filesystems in a persistent way, in which case the restart of the machine is automatically re-mounted after the machine has been restarted.

To do this, open the / etc / fstab file and add the following line as previously configured:

//bnd-asztali-v/Megosztás /mnt/asztali-megosztás cifs credentials=/home/botond/.asztali-v-credentials,uid=botond,iocharset=utf8,sec=ntlm       0       0

Of course, modify the parameters according to our own design.

Troubleshooting

Here I am going to describe my own experience in the event of a breakdown of Windows sharing.

If you are using Windows sharing massively under Linux, writing and reading large amounts of data at the same time, Windows may drop the connection.

After a long search, I finally found the solution, or two:

The shorter and faster solution is to open a DOS command prompt window on your Windows machine and then restart the server service:

net stop Server
net start Server

Then the connection to the shared library will be restored. If not, Linux will require even a new mount. But at this point, my relationship was restored.

Of course, this is just a quick patch, so the following is a more durable solution.

A more durable solution

There is a more durable solution that does not occur repeatedly. This needs to be resolved in the Windows registry. 

Run in Windows a regedit then navigate to the following point:

HKEY_LOCAL_MACHINE / SYSTEM / CurrentControlSet / Services / LanmanServer / Parameters /

And here, set the value of Size from the factory 1 to 3, and create a new DWORD (32 bit) field called "SMB2" and give it the value 0.

Then restart your Windows computer and it will no longer disconnect. At least I haven't had it in about a year and a half.

This after so many searches I found it here, many thanks for solving this problem!

Access Samba sharing from another Linux computer

There is still this variation when it comes to accessing a Samba share from another Linux computer.

Of course, you can share between two Linux systems NFS file sharing method However, if you have more than one computer on a network, it's a good idea to choose a Samba share so that Windows machines can conveniently use shared directories.

The Samba share must be mounted almost in the same way as the Windows share described above, except that the options do not use the ntlm encryption method.

So, the mount command looks like this:

mount -t cifs //<távoli gép>/<megosztás> /<helyi csatolási pont> -o credentials=/<credentials fájl>,uid=<helyi felhasználó>,gid=<helyi csoport>,iocharset=utf8

And the fstab entry:

//<távoli gép>/<megosztás> /<helyi csatolási pont> cifs credentials=/<credentials fájl>,uid=<helyi felhasználó>,gid=<helyi csoport>,iocharset=utf8	0	0

When specifying the options parameter block, make sure that there is no space around the commas separating the options, as they are considered another parameter. Also, the paths (mount point, credentials file) should always be absolute paths, which is why I made the / initials.

More useful settings on the Linux side

If you mount Windows shares in the fstab file on the Linux side, or even Samba shares on another Linux machine, you can add some more options to the options that already exist in the fstab line. So you can insert the following options before, behind or even between options, separated by commas, without spaces, just like the other options.

Masking privileges

By default, a file system mounted with CIFS, such as NTFS, does not store UNIX-like permissions on directories and files. Therefore, the filesystem mounted on it will have 777 permissions (rwxrwxrwx) on both directories and files. This is not the most perfect, because all the rights to directories and files are unnecessarily added. To set up the right authorization structure for us, we need to use masquerading. This is what the dir_mode and the file_mode options for mount CIFS file systems.

So if you want to set a normal permissions system, which is "drwxr-xrx" (755) for directories and "-rw-r - r--" (644) for files, specify them octal , which can be inserted into the existing options:

...,dir_mode=0755,file_mode=0644,...

About all CIFS mount options a on the mount.cifs manual page get information.

Troubleshoot network errors

If a network problem occurs during the startup of the Linux client machine, or if the configured Samba share is not available on the network (for example, the server is not yet turned on in a home network), the systemd by default, it waits for 90 seconds to access the share, and then the boot process may stop with an error if it does not reach the share after that. To eliminate this, use nofail and that x-timeout-systemd.device options. The first is simply specified, so that if the specified mount is not available, it does not stop with an error, and the second is to specify the maximum waiting time for the file system to be mounted.

For example:

...,nofail,x-systemd.device-timeout=1s,...

So even if the machine running the Samba server is not turned on by accident, the client starts up without problems. On the fly, you can mount the file system which is now available by mount "-a".

Conclusion

In this long description, we looked at how file sharing works with Samba, as well as how to connect to directories shared on other machines. So now you can easily set up shares on an office network of mixed systems.

Of course, Samba and cifs mount have many other setup options, but the knowledge described here is enough for everyday use.

Navigation