Difference between revisions of "Windows network share integration for linux"

Latest revision as of 00:30, 14 June 2021

Samba was developed in the early 1990s as a way for Linux users to access windows shares as well as enabling the use of a Linux file server to emulate a Windows file server. In over 20 years a lot of exciting things have happened in the development of Linux CIFS Utils and Samba. However, one major achievement has been completely neglected. If a user wishes to have seamless mounting and access to a Windows share, under his own linux desktop login name to the windows network share of the same login name, independent of each login, and persistent after reboot, then there is no simple solution.

It is easy to setup a persistent mount of a network share upon boot by adding an entry into /etc/fstab. This is fine for a single user computer where network security concerns are not present, such as in a home network. However, with this approach, no matter who logs into the linux workstation, he will have access to the network shares under the login privileges of the static mount provided in /etc/fstab. So if Nicole logs into Tom's desktop computer under her Linux username nicole, she will have access to the network shares with Tom's network authority since he created entries in /etc/fstab to connect to the shares with his username and password.

So it is possible in operating systems such as Ubuntu 14.04 to use the built in file manager Nautilus (Nautilus is the name of the file manager in Ubuntu identified only as "Files" from the desktop GUI - and it should also be noted that Ubuntu devs plan to replace Nautilus in a future distro release) and browse the Microsoft Network with native CIFS support - no need to install Samba. Furthermore, when using this method, the user is prompted for a username and password to access the Windows CIFS share. This way now Nicole can access her own shares on the network and not as Tom.

So, we have discussed two methods of accessing Windows shares from the linux desktop (in reverse order):

1. Browse Network with Nautilus and click to mount via gvfs
2. Persistent static mounts in /etc/fstab

Note: The creation of persistent mounts using fstab will work in any distribution. Discussion on GVFS applies to the GNOME desktop and thus distributions using GNOME and gvfs. For KDE users the equivalent is KIO (kio). KIO does not make mount points available to non-KIO applications. Relates to: dolphin / konqueror / kio-smb

Ubuntu Nautilus Click to Mount

This seems pretty slick. Just click, supply credentials and mount. However, the access is not persistent after reboot, even when the option to make the mount saved. It is buggy. Also, the mount path is ugly!

• Files -> Browse Network -> Windows Network -> WINDOWS DOMAIN

Here is where you will see the desktop systems with windows file shares and/or the network file server, be it a Windows server or a Samba based file server such as a NAS device. However, about half the time absolutely nothing appears. Again, it is buggy. In testing on Ubuntu 14.04 it was necessary, sometimes, to close and open the Browse Network option several times in order to have visibility of the NAS file server and network shares.

Once the share is selected in Nautilus the user is prompted for a username and password. The files are now visible in Nautilus and look all nice and neat. However, when attempting to access the mount using console, or another program directly such as an mp3 player, it is difficult to find the mount. It is not in /mnt and it is not in /media. Rather it is ugly, like the following example:

/run/user/1001/gvfs/smb-share:server=[name],share=music/mp3/my favorite song.mp3

What the hell is that? Nautilus uses GVFS to connect on-demand to the windows share. GVFS is the virtual filesystem for the GNOME desktop. GVFS and CIFS work together to mount the share in a temporary gvfs path.

Who's going to want to find that or type all that in? It cannot be accessed directly in console as root.

bash: cd: gvfs: Permission denied

It can be accessed though, from console, as the same user that is in the windows session.

nicole@Acronix:/run/user/1001/gvfs/smb-share:server=athena,share=media$ 

Again, this is ugly. To solve the ugliness problem a process called gvfs-fuse-daemon is supposed to create a pretty symlink to a subfolder of the user home folder. It should be under

/home/nicole/gvfs

It should be accessible when typing something like this:

cd ~/.gvfs

However, in our fresh install of Ubuntu 14.04 no such symlink was created and the tidy little path is unavailable. Again, buggy. It is possible this isn't even a bug, perhaps the feature was simply dropped.

We can create symlinks for these ugly paths. The symlinks will be persistent. However, the symlinks will appear broken until the share is manually browsed using Nautilus. Again, this is going to depend on what mood Nautilus is in and CIFS.

Mount via manual execute of mount command

CLI solution, execute the mount command or create a shell script that mounts multiple network drives. This way passwords need not be present in fstab or somewhere easily readable by other system users.

examples:

sudo mount -t cifs -o username= //WIN_SHARE_IP/ /mnt/WIN_SHARE

sudo mount -t cifs -o username=nicolep //192.168.1.10/public /mnt/public

sudo mount -t cifs -o username=nicolep //servername/public /mnt/public

Persistent Mount in fstab

The process for making a persistent mount by editing the /etc/fstab involves supplying the Windows network login credentials, including password, in this text file readable by all system users.

fstab example: persistent mounts using exposed credentials

There are more than one ways to do this. This example uses cifs to permanently mount the shares so that they will be available after reboot. If the system complains add the 'noauto' parameter.

• First edit your /etc/hosts file and add the hostname and IP address of the windows share or file server
• Next create mount points in /mnt for each windows share
• Make sure you have cifs installed
• Edit /etc/fstab and add a line for each windows share, see examples:

//apollo/public/ /mnt/public cifs username=nicolep,password=yourpass,iocharset=utf8,sec=ntlm  0  0
//apollo/media/ /mnt/media cifs username=nicolep,password=yourpass,iocharset=utf8,sec=ntlm  0  0
//apollo/video/ /mnt/video cifs username=nicolep,password=yourpass,iocharset=utf8,sec=ntlm  0  0

• mount the shares

mount -a

• This provides read-only access to the network shares.

Example with file permission specified and full rw access

//apollo/public /mnt/public cifs defaults,dir_mode=0777,file_mode=0777,domain=workgroup,username=nicolep,password=yourpass,uid=1000

troubleshooting: devs keep breaking samba

KERNEL CHANGE BREAKS CIFS.

Somewhere between kernel 4.10.0-38 4.15.0-20 a change was made that COULD PREVENT your cifs shares from mounting. Kernels at and before 4.10 used SMB (Server Message Block) version 1.0 as the default if not specified. Most folks did not specify it so it defaulted to 1.0 and worked. Microsoft ditched 1.0 in Windows 10 and dropped support. Linux kernel developers decided to change the kernel code to no longer default to SMB 1.0 and now default to a newer version. For people that are using legacy networks or NAS devices, it breaks the mounting example from above.

Solution: Specify the SMB version.

The solution is to tell mount.cifs to use the SMB2, SMB2.1 or SMB3.0 protocol using the "vers" parameter. in Linux CIFS Utils and Samba Specify 1.0, 2.0, 2.1, or 3.0.

For the following full line example a linux desktop is connecting to an older NAS device. It is necessary to specify SMB version 1.0. Example:

//apollo/video/ /mnt/video cifs defaults,vers=1.0,domain=workgroup,username=nicolep,password=mythtv,iocharset=utf8,sec=ntlm 0 0

FAILED TO CLOSE BROKEN PIPE

Update 2024 Kernel 5.15 Samba 2:4.15.13+dfsg-0ubuntu1.6 -

cp: failed to close 'filename': Broken pipe

A problem with this latest at the time samba Can't copy large files to Windows share - Error closing file: Input/output error issue workaround, specify prior version of cifs on fstab, see example:

//apollo/video/ /mnt/video cifs vers=2.0,defaults,domain=workgroup,username=nicolep,password=yourpass,uid=1000

The above example comes from our Mythbuntu configuration page. As you can see, besides the problem with all system users having access to the share as the one specific network user, that network username and password are exposed in this public readable file. Any user of the desktop now knows the username and password of the windows share owner. /etc/fstab is readable by everyone and so is your Windows password in it.

Another problem with the Mythbuntu example above is that you will not have write permissions to the mounted shares. To have write permissions it is necessary to specify the UID. We also should specify the workgroup name to speed up the process.

//athena/public/ /mnt/public cifs domain=workgroup,username=nicole,password=mythtv,uid=1001,iocharset=utf8,sec=ntlm 0 0
//athena/media/ /mnt/media cifs domain=workgroup,username=nicole,password=mythtv,uid=1001,iocharset=utf8,sec=ntlm 0 0

Lets assume our workgroup/domain name is "workgroup". Nicole now has the ability to both read and write to the shares.

We still have the exposing of your windows network security credentials issue. By using a credentials file we can hide the password.

vi ~/.smbcredentials

Enter the username and password

username=nicole
password=mythtv

Change the permissions of the file to prevent unwanted access to your credentials:

chmod 600 ~/.smbcredentials

Now edit fstab

vi /etc/fstab

Use:

//athena/public/ /mnt/public cifs domain=workgroup,credentials=/home/ubuntuusername/.smbcredentials,uid=1001,iocharset=utf8,sec=ntlm 0 0
//athena/media/ /mnt/media cifs domain=workgroup,credentials=/home/ubuntuusername/.smbcredentials,uid=1001,iocharset=utf8,sec=ntlm 0 0

Another security implementation to explore is using libpam_mount which may not work in Ubuntu 14.04 and is not covered here.

We still have the problem of all of our linux desktop users having access to the windows share as the one windows network user. One workaround is to mount during the login process rather than at boot. However, the mount then remains even after the user logs off. The system would need to be rebooted or the mount manually removed before logging out.

Hybrid Solution

Some users implement a hybrid of both systems to achieve a working solution. Consider that there may be public shares that you are indifferent as to whether all users have read write permission and there are personal or restricted shares that you want to limit access to. Lets define an example.

You may have a music share that you wish to have publicly accessible to all network users, read-only so that they do not delete any of your favorite songs.

You also have a private share that you wish only to be accessible by you.

This is a simple example. Considering this and the examples above, you should be able to construct any combination you desire for your own network needs.

Lets create a user on the file server or NAS device called music. Music can have read-only or read-write access defined on the file server as we will further restrict by the way we mount on our workstation. On the workstation we modify fstab.

vi /etc/fstab

And we add the following line:

//fileserver/media/ /mnt/media cifs domain=workgroup,username=music,password=music,iocharset=utf8,sec=ntlm  0  0

Our file server or NAS name is "fileserver" and our mp3 files are on a share called "media." Our domain is called "WORKGROUP" which is where "fileserver" resides. Our username and password are both set to "music." Now with execution of the mount -a

mount -a

We have a persistent share to access our music accessible on /mnt/media. No matter what user is on our workstation using his own login, he will have access to the music. Access is restricted to read-only since no UID was set.

For our own private share we will access it via Nautilus. Lets use nicole as our username. Nicole has a user id as defined in /etc/passwd as 1001. We need to know this. With Nautilus (identified only as Files in Unity) we do the following:

• Files -> Browse Network -> Windows Network -> WORKGROUP

Find the share called "nicoleshome" and click. Nicole (you) supplies her username and password. The connection is made (if there is no glitch.) If the share is not visible, close and try again.

Now that we have established the temporary connection, lets create a symbolic link from the ugly path to a nice tidy one in our own home folder.

ln -s /run/nicole/1001/gvfs/smb-share:server=fileserver,share=nicoleshome/My\ Documents /home/nicole/My\ Documents

Now, from nicole's own home directory we have access to all of her personal files in the network share "My Documents." The path for her to access them is simply:

/home/nicole/My Documents

However, the My Documents symlink will be broken after a new desktop session or of a timeout occurs until Nicole manually opens Nautilus and brows the path manually, supplying her username and password once again. Then the symbolic link in her home directory ones again becomes active.

This is a hybrid system utilizing both methods.

Mounting shares on local workstation login

Use ~/.xprofile, this is sourced by at least the GDM, LDM, LightDM and LXDM login managers.

Ubuntu 14.04 uses upstart tasks.

~/.config/upstart/desktopOpen.conf
~/.config/upstart/desktopClose.conf

Goal: When user 'nicole' logs into her linux desktop x session a script mounts all her cifs shares using her network security credentials. Now, during her x session she has access to the shares throughout the duration of the session. When she logs out then a script unmounts the shares.

Status: Theoretical. I have not had time to put this together and test. Once done I will document the configuration here.

Another option to try is to use the "gvfs-mount" command on login.

gvfs-mount smb://servername/share/

more to come...

Development Changes

Ubuntu devs plan to discontinue use of Nautilus soon, mostly because the folks that make Nautilus have gone astray. KDE uses Konqueror and before that KFM. Each have different ways of handling network browsing. Some of the documentation here may remain current longer than other parts. Readers are invited to edit this page to help maintain up-to-date documentation.