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

Popular posts from this blog

An attempt at full-disk encryption: Vera Crypt

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 testing full-disk encryption using VeraCrypt . Environment & required functionality Full-disk encryption needs to run on the following machines: The Linux Mint Xfce 18.3 laptop " Gandalf "; The Windows 10 laptop " Legolas ". The objective requirement is to protect user data from the physical theft of the physical machine, to provide an additional line of defence against data loss. This is probably more important for Windows than for Linux Mint.   Even so, in both cases, the operating system is likely to log activity which can reveal personal data and user (meta)data. Full-disk encryption does not mitigate against Microsoft’s sinister telemetry functionality, for which the main solutions seem to be: Either to use tools whose developers are constantly on the prowl, hunting for t

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

Partial decommissioning of Gandalf

The project is to build a Linux Mint machine to have the identical functionality and ergonomics as the existing Windows 10 machine. After a few months of continuous use of Linux Mint – mainly for simple browsing during workday lunchtimes and weekdays –   the headline of the project remains that wholesale migration from Windows to Linux is not functionally possible , for the reasons cited therein.   In this instance, the short story is no Microsoft Excel, no Foxit PDF browser for Windows, no on-the-fly VPN client. Consequently, there is no further development use of Gandalf.   Gandalf has other issues as well: even in last days as a Windows machine, the hard drive had developed a nasty habit of intensive operation, wasting time and resources on misadventure not commanded by the user.   The habit has returned to Gandalf as a Linux machine, meaning that the user needs to sit around for up to fifteen minutes from time-to-time while Gandalf faffs around for no good reason.   There