Skip to main content

Featured post

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 functionalityFor 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 Linux Mint by default.  If uninstalled following advice fr…

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