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

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.

Status report: wholesale migration from Windows to Linux is not functionally possible

As at mid-May2019 , it was clear that the path to migration from Windows to Linux was obstructed by a lack of apps that are fit-for-purpose being available in the Linux environment. Since May2019, there has been no change to the apps/functionalities then listed in the section, "Path to migration is obstructed by apps which are incompatible or otherwise unusable." Developments in the interim have merely confirmed that the apps available for the Linux environment are not fit-for-purpose, and are unlikely to be fit-for-purpose for the foreseeable future . So, it's time for a change of tack. The time is right to deploy Occam's Razor. In short, the Linux Mint offers a perfect solution to the jaded Windows user. The only problem with Linux Mint is not of Linux Mint's making. The problem is a lack of apps that are fit-for-purpose in the Linux environment. By fit-for-purpose, I mean apps that meet the hygiene requirements of office-based, corporate lackeys wh...

A Windows user tries out Linux Mint

Search This Blog