Skip to main content

A fail: networking Linux Mint to Windows using CIFS

The project is to build a Linux Mint machine to have the identical functionality and ergonomics as the existing Windows 10 machine.  This stage relates to networking the Windows 10 machine to the Linux Mint machine.

Environment & required functionality

The network should be a local network - to share files and folders - between the following machines:
  • The Linux Mint Xfce 18.3 laptop "Gandalf";
  • The Windows 10 laptop "Legolas".
The network is a local area network from a domestic router, the usual 192.168.x.x thing.

This is the third attempt to share files and folders between Windows and Linux Mint.  This third attempt reversed the relationship between the two machines.  Whereas the first two attempts had Windows as the client to Linux's server, this attempt made Windows the server and Linux the client.

This test failed to meet its core objectives.

Alternatives

Peer-to-peer networking (file sharing, simple two-way server-and-client relationship) is the most efficient way for bulk data transfers, so if the network doesn’t work, then the test has failed.

Software selection

In this test, neither Windows nor Linux Mint should have needed any additional software installed.  Linux Mint Xfce 18.3 has cifs-utils pre-installed.  Existing software needed either configuration or use.

Unfortunately, as part of the debug, it became necessary to install nfs-common, which subsequently had no effect.  So that got uninstalled by the end of the test.

Installation & configuration experience

The basic configuration is to set files/folders in Windows as shared objects, for Linux to then find them.

For Windows, the basic configuration instructions come in two flavours:
  • in Windows Server.  This does not apply in this test, because Legolas is Windows 10 Home, not Windows Server.
  • in Windows Home, or any workstation environment.
For Linux, the basic configuration is two stages:
  • to define a local folder whose purpose is to contain a link to a network share;
  • to point the local folder to the network share.
The Linux stage is set out more clearly by howtogeek than by unix.stackexchange.

User experience

The Windows side of the configuration was easy.  The script from howtogeek was easy to follow and the GUI prompted the user to find the necessary controls.

The Linux side of the configuration failed.  It did not do what the scripts said it should do.  Debug pointed towards the firewall ufw, but in spite of various attempts, the attempt to mount a Windows share to a Linux folder failed.

The Linux command that should have simply done the job was:
sudo mount -t nfs 192.168.0.16:/testsharetocif ~/testcifs

This failed with the error:
mount: wrong fs type, bad option, bad superblock on 192.168.0.16:/testsharetocif, missing codepage or helper program, or other error (for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.<type> helper program)

In some cases useful info is found in syslog - try dmesg | tail or so.

Hence the installation of nfs:
sudo apt-get install nfs-common

Which resulted in absolute silence from all subsequent attempts to mount, literally nothing happened until the user interrupted the timeout with CTRL+C:

administrator@GANDALF ~ $ sudo mount -t nfs 192.168.0.16:/testsharetocif ~/testcifs
^C
administrator@GANDALF ~ $ 

The log file as suggested by mount itself pointed towards a ufw block, as below, but this appeared to be a red herring.

administrator@GANDALF ~ $ dmesg | tail
[47598.959881] [UFW BLOCK] IN=wlp4s0 OUT= MAC=01:00:5e:00:00:01:48:d3:43:0b:69:70:08:00 SRC=192.168.0.1 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=44680 PROTO=2 
[47723.889000] [UFW BLOCK] IN=wlp4s0 OUT= MAC=01:00:5e:00:00:01:48:d3:43:0b:69:70:08:00 SRC=192.168.0.1 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=44688 PROTO=2 
[47848.920528] [UFW BLOCK] IN=wlp4s0 OUT= MAC=01:00:5e:00:00:01:48:d3:43:0b:69:70:08:00 SRC=192.168.0.1 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=44696 PROTO=2 
[47973.849515] [UFW BLOCK] IN=wlp4s0 OUT= MAC=01:00:5e:00:00:01:48:d3:43:0b:69:70:08:00 SRC=192.168.0.1 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=44704 PROTO=2 
[48081.548700] NFS: Registering the id_resolver key type
[48081.548717] Key type id_resolver registered
[48081.548718] Key type id_legacy registered
[48098.880899] [UFW BLOCK] IN=wlp4s0 OUT= MAC=01:00:5e:00:00:01:48:d3:43:0b:69:70:08:00 SRC=192.168.0.1 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=44712 PROTO=2 
[48223.912258] [UFW BLOCK] IN=wlp4s0 OUT= MAC=01:00:5e:00:00:01:48:d3:43:0b:69:70:08:00 SRC=192.168.0.1 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=44720 PROTO=2 
[48348.943635] [UFW BLOCK] IN=wlp4s0 OUT= MAC=01:00:5e:00:00:01:48:d3:43:0b:69:70:08:00 SRC=192.168.0.1 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=44728 PROTO=2 
administrator@GANDALF ~ $ 

It turns out that 224.0.0.1 is a commonly used address for multi-casting, part of network discovery, so not much help.

After adjusting ufw for the most common ports used for mounting network shares, ufw's rule table looked like that below, and still mount failed with silence.

administrator@GANDALF ~ $ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
22                         ALLOW       Anywhere
Samba                      ALLOW       Anywhere
137/udp                    ALLOW       192.168.0.0/24
138/udp                    ALLOW       192.168.0.0/24
139/tcp                    ALLOW       192.168.0.0/24
445/tcp                    ALLOW       192.168.0.0/24
111                        ALLOW       192.168.1.0/24
2049                       ALLOW       192.168.1.0/24
111                        ALLOW       192.168.0.0/24
2049                       ALLOW       192.168.0.0/24
22 (v6)                    ALLOW       Anywhere (v6)
Samba (v6)                 ALLOW       Anywhere (v6)

Following this forum, the command gksudo xed /etc/default/nfs-kernel-server produced an empty file.  Nothing to comment out/replace.

At this point, the test was deemed failed and, in any event, was timed out at 2 hours solid testing.  Nothing should objectively be this difficult to work.

In Gandalf/Linux, the changes in this test were rolled back, the ufw firewall was reset and re-enabled.  In Legolas/Windows, the changes to the test folder's share properties were reversed.

It's a fail.

Conclusion

Linux Mint Xfce 18.3 was unable to mount a shared folder in Windows 10 after two hours.  The implication for this project is to move onto the next test, and attempt again to solve this issue on a different day.

Reflections

The implication of this finding for a typical Windows user is probably more profound: a typical Windows user migrating to Linux Mint would enough friction to deter the user from migration, and thus stick with Windows.

It seems bizarre that Linux Mint, a project ostensibly aimed at poaching Windows users into the Linux fold, published a distro (in this case, Xfce) that wasn't already configured to permit mount calls without incident.

Completed June 2018.

Comments

Post a Comment

Popular posts from this blog

Downgrading of the project: Calc has a fatal bug - it cannot reliably link workbooks

The project is to build a Linux Mint machine to have the identical functionality and ergonomics as the existing Windows 10 machine. This stage relates to on-going work to make LibreOffice Calc workable. Unfortunately, it turns out that LibreOffice isn't fit for purpose.  Specifically, it cannot reliably link workbooks, even in its own native workbooks. As a consequence, the project is now downgraded.  My time is now better spent doing other, more productive things, with a greater chance of success. Background On 29Jul2018, I complied a detailed test using fresh, sample data created specifically for the purpose, in Excel on Windows 10, then had a virtual machine running LibreCalc on Linux Mint to import it. The basic spreadsheet functionality of linked workbooks failed haphazardly. I logged the test results on 29Jul2018 on AskLibreOffice  and, to date, have yet to see any evidence of anybody taking ownership of recognising the issue and thus fixing it. The s...
Post a Comment
Read more

The Big Bang: Microsoft Windows goes for good, positive adaptations required

On 27Mar2021, Linux Mint ate Microsoft Windows 10 on Legolas. Three months on, I conclude beyond any doubt that wiping out Windows was the best decision I ever made. The second best decision I ever made was to test Linux Mint in Virtual Box five years ago. The third best decision I ever made was to take ownership of the learning curve that migrating in Windows really entails. A quick reminder: what’s Microsoft Windows like nowadays? I still need to use Windows at work. I cannot easily describe how painful it now is to use Windows. So I’ll try to describe it difficultly. My work machine is a powerful beast, but it exhibits constant latency. For a keyboard-orientated power user, this means that some keystrokes go walkabouts when other services on the Windows machine go to nuclear war with each other, scrambling to feed their narcissistic self-importance for besieged system resources wholly at the user’s expense. Something on Windows tends to clear the keyboard buffer randomly, resulting ...
Post a Comment
Read more

Deployment of Wine

The project is to build a Linux Mint machine to have the identical functionality and ergonomics as the existing Windows 10 machine. Having established that there is no way to migrate fully from Windows to Linux , the project now needs to consider running Windows apps in Linux.   This is a big change to the strategy of the project.   This is a big change to the deployment of a Linux workstation, a crushing admission of failure, and the opening of a whole new world of risks to an otherwise secure operating system. Environment & required functionality For this blog post, Wine was tested on: The Linux Mint Xfce 19 virtual machine " Bilbo ", on host Windows 10 laptop " Saruman " The Linux Mint Xfce 18.3 virtual machine " Gimli ", on host Windows 10 host " Legolas ". Alternatives There are alternatives to Wine/PlayOnLinux, notably the paid software Crossover. Software selection Wine and PlayOnLinux are present in L...
Post a Comment
Read more