Installing TrueType font files in Lubuntu 22.04

Yesterday I looked through some old CDROMs with a view to disposing of them. I came across one from 2001 from a company called Focus Multimedia Limited, titled ‘4,000 fonts – A comprehensive collection of stylish and professional fonts’ for Windows 95 / 98 / Me / NT / 2000 / XP. It is still readable and contains both PostScript and TrueType font files, as well as a Windows application called BOSS Font Manager to view the fonts.

I decided to install the TTF fonts on one of my machines: the family desktop running Lubuntu 22.04. I followed one of the many articles on the Web regarding installing TTF fonts in Ubuntu, but LibreOffice did not list the new fonts in its drop-down menu of fonts. It turned out I needed one more step in order to make the new fonts accessible: I needed to change the permissions of the TTF files that I had copied to the Linux fonts directory. Anyway, below I list all the steps I followed in order to install the new TTF fonts.

1. I inserted the CDROM in the machine’s optical drive

Lubuntu mounted it automatically onto /media/fitzcarraldo/BOSSFONTS/, and a directory /media/fitzcarraldo/BOSSFONTS/Fonts/ contained two sub-directories PSFonts and TTfonts. The latter sub-directory contained sub-directories named ‘A‘ to ‘Z‘, each containing *.ttf font files.

2. I created a system-wide sub-directory for the new font files

As the fonts appear to be from a US company called Arts & Letters, and the CDROM is labelled ‘BOSSFONTS‘, I chose a sub-directory name ‘BossFonts‘ to hold the font files in the Lubuntu system, in order to keep the system directory /usr/share/fonts/ tidy and to segregate the new font files:

user $ sudo mkdir /usr/share/fonts/BossFonts

3. I copied the font files to the directory

user $ sudo cp -r /media/fitzcarraldo/BOSSFONTS/Fonts/TTfonts/*/*.ttf /usr/share/fonts/BossFonts/

4. I updated the system’s font cache

user $ sudo fc-cache -f -v

5. I checked if the fonts were installed

user $ fc-list | grep "BossFonts"

Everything seemed OK, but, when I launched LibreOffice Writer, the new fonts were not shown in Writer’s drop-down menu of fonts.

6. I checked the permissions of already-existing font files and the new font files

user $ ls -la /usr/share/fonts/truetype/noto | head -n 5
total 1132
drwxr-xr-x  2 root root   4096 Jan 10  2022 .
drwxr-xr-x 57 root root   4096 Nov 24  2021 ..
-rw-r--r--  1 root root 107848 Nov 10  2020 NotoMono-Regular.ttf
-rw-r--r--  1 root root 523412 Dec 26  2020 NotoSansMono-Bold.ttf

user $ ls -la /usr/share/fonts/BossFonts/ | head -n 5
total 129260
drwxr-xr-x 2 root root  69632 Apr 23 10:18 .
drwxr-xr-x 9 root root   4096 Apr 23 10:16 ..
-r-------- 1 root root  41868 Apr 23 10:18 ache___b.ttf
-r-------- 1 root root  40868 Apr 23 10:18 ache__cb.ttf

7. I changed the permissions of the new font files

user $ sudo chmod 644 /usr/share/fonts/BossFonts/*.ttf

user $ ls -la /usr/share/fonts/BossFonts/ | head -n 5
total 129260
drwxr-xr-x 2 root root  69632 Apr 23 10:18 .
drwxr-xr-x 9 root root   4096 Apr 23 10:16 ..
-rw-r--r-- 1 root root  41868 Apr 23 10:18 ache___b.ttf
-rw-r--r-- 1 root root  40868 Apr 23 10:18 ache__cb.ttf

Now LibreOffice Writer lists all the fonts. Job done.

Investigating an OpenVPN connection problem in Gentoo Linux and Lubuntu 22.04 but not in Android 13

Back in 2020 I successfully used OpenVPN to access a remote server from my laptop and from my smartphone. Fast forward to 2023 and I needed to use OpenVPN again to access the same remote server. I could again access the remote server when connecting from my smartphone, now running Android 13, using the OpenVPN client app. However, when I tried to use OpenVPN from my laptop running Gentoo Linux, and from my desktop machine running Lubuntu 22.04, VPN connection attempts always timed out. The OpenVPN client configuration file (referred to generically as ‘client.ovpn‘ in some articles, named ‘bsf1.ovpn‘ in my case) and the OpenVPN password were both correct, so I did not understand why a connection could not be established from the laptop and desktop machine to the remote server, especially as there was not a problem connecting from my smartphone running Android 13.

I use KDE in Gentoo Linux, and Lubuntu 22.04 uses LXQt. In both those Desktop Environments I used the relevant GUI front-end to NetworkManager to import the client.ovpn file and to try to connect to the VPN server. As these connection attempts had failed, I launched the OpenVPN client from the command line in Gentoo Linux to see if there were any error messages, and the output is shown below. (For privacy reasons I have annonimised my public IP address, domain, e-mail address, country, location and organisation in all the command line output shown in this post.)

root # openvpn --config bsf1.ovpn
2023-09-30 01:07:02 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2023-09-30 01:07:02 DEPRECATED OPTION: --cipher set to 'AES-128-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations. 
2023-09-30 01:07:02 OpenVPN 2.6.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
2023-09-30 01:07:02 library versions: OpenSSL 3.0.10 1 Aug 2023, LZO 2.10
2023-09-30 01:07:02 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Enter Private Key Password:
2023-09-30 01:08:57 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2023-09-30 01:08:58 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 01:08:58 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 01:08:58 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 01:08:58 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 01:08:58 TCPv4_CLIENT link local: (not bound)
2023-09-30 01:08:58 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 01:08:58 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
2023-09-30 01:08:58 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=fc150984 3a9d3b4f
2023-09-30 01:08:58 TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
2023-09-30 01:08:58 OpenSSL: error:0A000102:SSL routines::unsupported protocol
2023-09-30 01:08:58 TLS_ERROR: BIO read tls_read_plaintext error
2023-09-30 01:08:58 TLS Error: TLS object -> incoming plaintext read error
2023-09-30 01:08:58 TLS Error: TLS handshake failed
2023-09-30 01:08:58 Fatal TLS error (check_tls_errors_co), restarting
2023-09-30 01:08:58 SIGUSR1[soft,tls-error] received, process restarting
2023-09-30 01:08:58 Restart pause, 1 second(s)
2023-09-30 01:08:59 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-09-30 01:08:59 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 01:08:59 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 01:08:59 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 01:08:59 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 01:08:59 TCPv4_CLIENT link local: (not bound)
2023-09-30 01:08:59 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 01:08:59 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=00c193e4 f375c3df
2023-09-30 01:08:59 TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
2023-09-30 01:08:59 OpenSSL: error:0A000102:SSL routines::unsupported protocol
2023-09-30 01:08:59 TLS_ERROR: BIO read tls_read_plaintext error
2023-09-30 01:08:59 TLS Error: TLS object -> incoming plaintext read error
2023-09-30 01:08:59 TLS Error: TLS handshake failed
2023-09-30 01:08:59 Fatal TLS error (check_tls_errors_co), restarting
2023-09-30 01:08:59 SIGUSR1[soft,tls-error] received, process restarting
2023-09-30 01:08:59 Restart pause, 1 second(s)
2023-09-30 01:09:00 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-09-30 01:09:00 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:00 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 01:09:00 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:00 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:00 TCPv4_CLIENT link local: (not bound)
2023-09-30 01:09:00 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:00 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=415fddcd dc5faf65
2023-09-30 01:09:01 TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
2023-09-30 01:09:01 OpenSSL: error:0A000102:SSL routines::unsupported protocol
2023-09-30 01:09:01 TLS_ERROR: BIO read tls_read_plaintext error
2023-09-30 01:09:01 TLS Error: TLS object -> incoming plaintext read error
2023-09-30 01:09:01 TLS Error: TLS handshake failed
2023-09-30 01:09:01 Fatal TLS error (check_tls_errors_co), restarting
2023-09-30 01:09:01 SIGUSR1[soft,tls-error] received, process restarting
2023-09-30 01:09:01 Restart pause, 1 second(s)
2023-09-30 01:09:02 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-09-30 01:09:02 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:02 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 01:09:02 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:02 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:02 TCPv4_CLIENT link local: (not bound)
2023-09-30 01:09:02 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:02 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=1458e510 821d0c37
2023-09-30 01:09:02 TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
2023-09-30 01:09:02 OpenSSL: error:0A000102:SSL routines::unsupported protocol
2023-09-30 01:09:02 TLS_ERROR: BIO read tls_read_plaintext error
2023-09-30 01:09:02 TLS Error: TLS object -> incoming plaintext read error
2023-09-30 01:09:02 TLS Error: TLS handshake failed
2023-09-30 01:09:02 Fatal TLS error (check_tls_errors_co), restarting
2023-09-30 01:09:02 SIGUSR1[soft,tls-error] received, process restarting
2023-09-30 01:09:02 Restart pause, 1 second(s)
2023-09-30 01:09:03 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-09-30 01:09:03 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:03 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 01:09:03 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:03 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:03 TCPv4_CLIENT link local: (not bound)
2023-09-30 01:09:03 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:03 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=9ab3df76 86d3e81d
2023-09-30 01:09:03 TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
2023-09-30 01:09:03 OpenSSL: error:0A000102:SSL routines::unsupported protocol
2023-09-30 01:09:03 TLS_ERROR: BIO read tls_read_plaintext error
2023-09-30 01:09:03 TLS Error: TLS object -> incoming plaintext read error
2023-09-30 01:09:03 TLS Error: TLS handshake failed
2023-09-30 01:09:03 Fatal TLS error (check_tls_errors_co), restarting
2023-09-30 01:09:03 SIGUSR1[soft,tls-error] received, process restarting
2023-09-30 01:09:03 Restart pause, 2 second(s)
2023-09-30 01:09:05 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-09-30 01:09:05 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:05 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 01:09:05 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:05 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:05 TCPv4_CLIENT link local: (not bound)
2023-09-30 01:09:05 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:05 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=9f21e4f5 a4d9fecb
2023-09-30 01:09:05 TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
2023-09-30 01:09:05 OpenSSL: error:0A000102:SSL routines::unsupported protocol
2023-09-30 01:09:05 TLS_ERROR: BIO read tls_read_plaintext error
2023-09-30 01:09:05 TLS Error: TLS object -> incoming plaintext read error
2023-09-30 01:09:05 TLS Error: TLS handshake failed
2023-09-30 01:09:05 Fatal TLS error (check_tls_errors_co), restarting
2023-09-30 01:09:05 SIGUSR1[soft,tls-error] received, process restarting
2023-09-30 01:09:05 Restart pause, 4 second(s)
2023-09-30 01:09:09 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-09-30 01:09:10 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:10 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 01:09:10 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:10 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:10 TCPv4_CLIENT link local: (not bound)
2023-09-30 01:09:10 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:10 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=bb6d7166 52844953
2023-09-30 01:09:10 TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
2023-09-30 01:09:10 OpenSSL: error:0A000102:SSL routines::unsupported protocol
2023-09-30 01:09:10 TLS_ERROR: BIO read tls_read_plaintext error
2023-09-30 01:09:10 TLS Error: TLS object -> incoming plaintext read error
2023-09-30 01:09:10 TLS Error: TLS handshake failed
2023-09-30 01:09:10 Fatal TLS error (check_tls_errors_co), restarting
2023-09-30 01:09:10 SIGUSR1[soft,tls-error] received, process restarting
2023-09-30 01:09:10 Restart pause, 8 second(s)
2023-09-30 01:09:18 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-09-30 01:09:18 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:18 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 01:09:18 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:19 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:19 TCPv4_CLIENT link local: (not bound)
2023-09-30 01:09:19 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:19 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=099e3b11 8ddc87c1
2023-09-30 01:09:19 TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
2023-09-30 01:09:19 OpenSSL: error:0A000102:SSL routines::unsupported protocol
2023-09-30 01:09:19 TLS_ERROR: BIO read tls_read_plaintext error
2023-09-30 01:09:19 TLS Error: TLS object -> incoming plaintext read error
2023-09-30 01:09:19 TLS Error: TLS handshake failed
2023-09-30 01:09:19 Fatal TLS error (check_tls_errors_co), restarting
2023-09-30 01:09:19 SIGUSR1[soft,tls-error] received, process restarting
2023-09-30 01:09:19 Restart pause, 16 second(s)
2023-09-30 01:09:35 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-09-30 01:09:35 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:35 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 01:09:35 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:35 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 01:09:35 TCPv4_CLIENT link local: (not bound)
2023-09-30 01:09:35 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 01:09:35 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=38ffac21 50e59cc4
2023-09-30 01:09:35 TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
2023-09-30 01:09:35 OpenSSL: error:0A000102:SSL routines::unsupported protocol
2023-09-30 01:09:35 TLS_ERROR: BIO read tls_read_plaintext error
2023-09-30 01:09:35 TLS Error: TLS object -> incoming plaintext read error
2023-09-30 01:09:35 TLS Error: TLS handshake failed
2023-09-30 01:09:35 Fatal TLS error (check_tls_errors_co), restarting
2023-09-30 01:09:35 SIGUSR1[soft,tls-error] received, process restarting
2023-09-30 01:09:35 Restart pause, 32 second(s)
^C

The error message ‘TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled.‘ made me suspect that the version of the OpenSSL package (which also provides TLS) in Gentoo Linux on my laptop is incompatible with the version of the OpenSSL package on the remote server.

The command line output in Lubuntu 22.04 on the desktop machine also showed there was a problem with TLS when I tried to launch the VPN client:

user $ sudo openvpn --config bsf1.ovpn
[sudo] password for fitzcarraldo: 
2023-10-03 14:00:43 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2023-10-03 14:00:43 DEPRECATED OPTION: --cipher set to 'AES-128-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-128-CBC' to --data-ciphers or change --cipher 'AES-128-CBC' to --data-ciphers-fallback 'AES-128-CBC' to silence this warning.
2023-10-03 14:00:43 OpenVPN 2.5.5 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 14 2022
2023-10-03 14:00:43 library versions: OpenSSL 3.0.2 15 Mar 2022, LZO 2.10
2023-10-03 14:00:43 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
🔐 Enter Private Key Password: ************            
2023-10-03 14:00:48 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2023-10-03 14:00:48 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-10-03 14:00:48 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-10-03 14:00:48 RESOLVE: Cannot resolve host address: bsfitzgerald.ddns.net:1194 (Temporary failure in name resolution)
2023-10-03 14:00:48 RESOLVE: Cannot resolve host address: bsfitzgerald.ddns.net:1194 (Temporary failure in name resolution)
2023-10-03 14:00:48 Could not determine IPv4/IPv6 protocol
2023-10-03 14:00:48 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
2023-10-03 14:00:48 SIGUSR1[soft,init_instance] received, process restarting
2023-10-03 14:00:48 Restart pause, 5 second(s)
2023-10-03 14:00:53 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-10-03 14:00:53 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-10-03 14:00:53 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-10-03 14:00:55 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-10-03 14:00:55 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-10-03 14:00:55 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194 [nonblock]
2023-10-03 14:00:55 TCP connection established with [AF_INET]111.222.333.444:1194
2023-10-03 14:00:55 TCP_CLIENT link local: (not bound)
2023-10-03 14:00:55 TCP_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-10-03 14:00:56 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=c3ec9433 c4139af0
2023-10-03 14:00:57 VERIFY OK: depth=1, C=PE, ST=Loreto, L=Iquitos, O=Work, OU=vpn, CN=server, name=server, emailAddress=brian@bsfitzgerald.com
2023-10-03 14:00:57 VERIFY OK: depth=0, C=PE, ST=Loreto, L=Iquitos, O=Work, OU=vpn, CN=server, name=server, emailAddress=brian@bsfitzgerald.com
2023-10-03 14:00:58 OpenSSL: error:0A0C0103:SSL routines::internal error
2023-10-03 14:00:58 TLS_ERROR: BIO read tls_read_plaintext error
2023-10-03 14:00:58 TLS Error: TLS object -> incoming plaintext read error
2023-10-03 14:00:58 TLS Error: TLS handshake failed
2023-10-03 14:00:58 Fatal TLS error (check_tls_errors_co), restarting
2023-10-03 14:00:58 SIGUSR1[soft,tls-error] received, process restarting
2023-10-03 14:00:58 Restart pause, 5 second(s)
2023-10-03 14:01:03 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-10-03 14:01:03 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-10-03 14:01:03 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-10-03 14:01:03 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-10-03 14:01:03 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-10-03 14:01:03 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194 [nonblock]
2023-10-03 14:01:03 TCP connection established with [AF_INET]111.222.333.444:1194
2023-10-03 14:01:03 TCP_CLIENT link local: (not bound)
2023-10-03 14:01:03 TCP_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-10-03 14:01:03 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=486e45aa bbf5d0b0
2023-10-03 14:01:05 VERIFY OK: depth=1, C=GB, ST=Loreto, L=Iquitos, O=Work, OU=vpn, CN=server, name=server, emailAddress=brian@bsfitzgerald.com
2023-10-03 14:01:05 VERIFY OK: depth=0, C=GB, ST=Loreto, L=Iquitos, O=Work, OU=vpn, CN=server, name=server, emailAddress=brian@bsfitzgerald.com
2023-10-03 14:01:05 OpenSSL: error:0A0C0103:SSL routines::internal error
2023-10-03 14:01:05 TLS_ERROR: BIO read tls_read_plaintext error
2023-10-03 14:01:05 TLS Error: TLS object -> incoming plaintext read error
2023-10-03 14:01:05 TLS Error: TLS handshake failed
2023-10-03 14:01:05 Fatal TLS error (check_tls_errors_co), restarting
2023-10-03 14:01:05 SIGUSR1[soft,tls-error] received, process restarting
2023-10-03 14:01:05 Restart pause, 5 second(s)
2023-10-03 14:01:10 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-10-03 14:01:10 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-10-03 14:01:10 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-10-03 14:01:10 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-10-03 14:01:10 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-10-03 14:01:10 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194 [nonblock]
2023-10-03 14:01:10 TCP connection established with [AF_INET]111.222.333.444:1194
2023-10-03 14:01:10 TCP_CLIENT link local: (not bound)
2023-10-03 14:01:10 TCP_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-10-03 14:01:11 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=2523066e a7169e23
2023-10-03 14:01:12 VERIFY OK: depth=1, C=GB, ST=Loreto, L=Iquitos, O=Work, OU=vpn, CN=server, name=server, emailAddress=brian@bsfitzgerald.com
2023-10-03 14:01:12 VERIFY OK: depth=0, C=GB, ST=Loreto, L=Iquitos, O=Work, OU=vpn, CN=server, name=server, emailAddress=brian@bsfitzgerald.com
2023-10-03 14:01:13 OpenSSL: error:0A0C0103:SSL routines::internal error
2023-10-03 14:01:13 TLS_ERROR: BIO read tls_read_plaintext error
2023-10-03 14:01:13 TLS Error: TLS object -> incoming plaintext read error
2023-10-03 14:01:13 TLS Error: TLS handshake failed
2023-10-03 14:01:13 Fatal TLS error (check_tls_errors_co), restarting
2023-10-03 14:01:13 SIGUSR1[soft,tls-error] received, process restarting
2023-10-03 14:01:13 Restart pause, 5 second(s)
^C

The version of OpenSSL currently running on the remote server is as follows:

user $ openssl version
OpenSSL 1.0.2l  25 May 2017

whereas the version of OpenSSL currently running in Gentoo Linux on the laptop is:

user $ openssl version
OpenSSL 3.0.10 1 Aug 2023 (Library: OpenSSL 3.0.10 1 Aug 2023)

and the version of OpenSSL currently running in Lubuntu 22.04 on the desktop machine is:

user $ openssl version
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)

The last time I successfully used the OpenVPN client on the laptop was in 2020, when the version of OpenSSL on the laptop was 1.1.1g, so my suspicion grew that the root cause of the problem is a version difference in OpenSSL between the client machine and the remote server.

I searched the Web and found OpenVPN bug report #348: ‘2.6 client cannot connect to old 2.2 and 2.1 server‘. Therefore I tried adding the following three lines to the client.ovpn file (bsf1.ovpn) in Gentoo Linux:

tls-cert-profile insecure
providers legacy default
compat-mode 1.1.1

Now the laptop can connect to the remote VPN server via the command line in a terminal window, as shown in the output below:

root # openvpn --config bsf1.ovpn
2023-09-30 03:13:26 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2023-09-30 03:13:26 OpenVPN 2.6.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
2023-09-30 03:13:26 library versions: OpenSSL 3.0.10 1 Aug 2023, LZO 2.10
2023-09-30 03:13:26 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Enter Private Key Password:
2023-09-30 03:13:33 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2023-09-30 03:13:33 TCP/UDP: Preserving recently used remote address: [AF_INET]111.222.333.444:1194
2023-09-30 03:13:33 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-09-30 03:13:33 Attempting to establish TCP connection with [AF_INET]111.222.333.444:1194
2023-09-30 03:13:33 TCP connection established with [AF_INET]111.222.333.444:1194
2023-09-30 03:13:33 TCPv4_CLIENT link local: (not bound)
2023-09-30 03:13:33 TCPv4_CLIENT link remote: [AF_INET]111.222.333.444:1194
2023-09-30 03:13:33 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
2023-09-30 03:13:33 TLS: Initial packet from [AF_INET]111.222.333.444:1194, sid=4103e161 8493e221
2023-09-30 03:13:34 VERIFY OK: depth=1, C=PE, ST=Loreto, L=Iquitos, O=Work, OU=vpn, CN=server, name=server, emailAddress=brian@bsfitzgerald.com
2023-09-30 03:13:34 VERIFY OK: depth=0, C=PE, ST=Loreto, L=Iquitos, O=Work, OU=vpn, CN=server, name=server, emailAddress=brian@bsfitzgerald.com
2023-09-30 03:13:35 Control Channel: TLSv1, cipher SSLv3 DHE-RSA-AES256-SHA, peer certificate: 2048 bit RSA, signature: RSA-SHA256
2023-09-30 03:13:35 [server] Peer Connection Initiated with [AF_INET]111.222.333.444:1194
2023-09-30 03:13:35 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
2023-09-30 03:13:35 TLS: tls_multi_process: initial untrusted session promoted to trusted
2023-09-30 03:13:36 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
2023-09-30 03:13:36 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-options DNS 8.8.8.8,route-gateway 10.10.1.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.10.1.4 255.255.255.0'
2023-09-30 03:13:36 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:2: dhcp-options (2.6.4)
2023-09-30 03:13:36 OPTIONS IMPORT: --ifconfig/up options modified
2023-09-30 03:13:36 OPTIONS IMPORT: route options modified
2023-09-30 03:13:36 OPTIONS IMPORT: route-related options modified
2023-09-30 03:13:36 Using peer cipher 'AES-128-CBC'
2023-09-30 03:13:36 net_route_v4_best_gw query: dst 0.0.0.0
2023-09-30 03:13:36 net_route_v4_best_gw result: via 192.168.96.245 dev wlp3s0
2023-09-30 03:13:36 ROUTE_GATEWAY 192.168.96.245/255.255.255.0 IFACE=wlp3s0 HWADDR=d8:fc:93:c5:f4:6d
2023-09-30 03:13:36 TUN/TAP device tun0 opened
2023-09-30 03:13:36 net_iface_mtu_set: mtu 1500 for tun0
2023-09-30 03:13:36 net_iface_up: set tun0 up
2023-09-30 03:13:36 net_addr_v4_add: 10.10.1.4/24 dev tun0
2023-09-30 03:13:36 net_route_v4_add: 111.222.333.444/32 via 192.168.96.245 dev [NULL] table 0 metric -1
2023-09-30 03:13:36 net_route_v4_add: 0.0.0.0/1 via 10.10.1.1 dev [NULL] table 0 metric -1
2023-09-30 03:13:36 net_route_v4_add: 128.0.0.0/1 via 10.10.1.1 dev [NULL] table 0 metric -1
2023-09-30 03:13:36 UID set to nobody
2023-09-30 03:13:36 GID set to nogroup
2023-09-30 03:13:36 Capabilities retained: CAP_NET_ADMIN
2023-09-30 03:13:36 Initialization Sequence Completed
2023-09-30 03:13:36 Data Channel: cipher 'AES-128-CBC', auth 'SHA256', compression: 'lzo'
2023-09-30 03:13:36 Timers: ping 10, ping-restart 12
[...]

and I can access the SMB shares on the remote server by entering ‘smb://192.168.0.10‘ in the Dolphin file manager’s window in KDE on the laptop.

However, if I terminate the openvpn client on the command line and then import the modified bsf1.ovpn file into NetworkManager using plasma-nm (the KDE GUI front-end to NetworkManager), connection attempts to the VPN still time out. The created NetworkManager connection file /etc/NetworkManager/system-connections/bsf1.nmconnection does not contain the settings in the additional three lines that I added to the client.ovpn file, as apparently they are meaningless to NetworkManager. When I use the plasma-nm GUI to import the client.ovpn file I assume plasma-nm or NetworkManager simply ignore the additional three lines when they parse the configuration file.

In Lubuntu 22.04 I edited bsf1.ovpn to add the three lines:

tls-cert-profile insecure
providers legacy default
compat-mode 1.1.1

and launched the openvpn client from the command line, but OpenVPN objected to the compat-mode line:

user $ sudo openvpn --config wjh1.ovpn
Options error: Unrecognized option or missing or extra parameter(s) in bsf1.ovpn:93: compat-mode (2.5.5)
Use --help for more information.

For the openvpn client command to execute successfully in Lubuntu 22.04 I had to omit the line ‘compat-mode 1.1.1‘, i.e. the two manually-added lines to bsf1.ovpn in Lubuntu 22.04 are:

tls-cert-profile insecure
providers legacy default

In my situation (i.e. the client is using OpenSSL 3.x.x in Lubuntu 22.04 and the remote server is using OpenSSL 1.x.x) the VPN connection still times out when attempting to connect using the GUI front-end (nm-tray or nm-applet) to NetworkManager in LXQt, so the work-around is still to launch the OpenVPN client from the command line as already explained:

user $ openvpn --conf bsf1.ovpn

and I can access the SMB shares on the remote server by entering ‘smb://192.168.0.10‘ in the PCManFM-Qt file manager’s window in LXQt on the desktop machine.

The remaining question I had was why my Samsung Galaxy Note 20 Ultra 5G running Android 13 can connect to the remote server via OpenVPN. I suspected that Android 13 uses an earlier version of OpenSSL that is compatible with the version on the remote server. A little research online showed me that Android 13 (and a couple of previous versions of Android) uses a Google fork of OpenSSL called BoringSSL. So, to find the version of OpenSSL/BoringSSL in Android 13, I cloned the BoringSSL repository on my laptop:

user $ git clone https://android.googlesource.com/platform/external/boringssl

and then I searched for the environment variable OPENSSL_VERSION_TEXT:

user $ grep -r OPENSSL_VERSION_TEXT boringssl/*
boringssl/include/openssl/crypto.h:// OPENSSL_VERSION_TEXT contains a string the identifies the version of
boringssl/include/openssl/crypto.h:#define OPENSSL_VERSION_TEXT "OpenSSL 1.1.1 (compatible; BoringSSL)"
boringssl/src/include/openssl/crypto.h:// OPENSSL_VERSION_TEXT contains a string the identifies the version of
boringssl/src/include/openssl/crypto.h:#define OPENSSL_VERSION_TEXT "OpenSSL 1.1.1 (compatible; BoringSSL)"
boringssl/src/crypto/crypto_test.cc:// Test that OPENSSL_VERSION_NUMBER and OPENSSL_VERSION_TEXT are consistent.
boringssl/src/crypto/crypto_test.cc:// Node.js parses the version out of OPENSSL_VERSION_TEXT instead of using
boringssl/src/crypto/crypto_test.cc:            std::string(OPENSSL_VERSION_TEXT).substr(0, strlen(expected)));

As I had surmised, OpenSSL (well, the fork BoringSSL) in Android 13 is Version 1.1.1. That is why the original bsf1.ovpn still works with the OpenVPN client on my phone to access the OpenVPN server running on the remote server.

By the way, in order to use OpenVPN in Lubuntu 22.04, you need to install the following three Ubuntu packages:

openvpn
network-manager-openvpn
network-manager-openvpn-gnome (despite Lubuntu using LXQt rather than GNOME)

The NetworkManager GUI front-end nm-tray does not support password asking, so you need to use the NetworkManager GUI front-end nm-applet to connect to the VPN (assuming both client and server have compatible versions of OpenSSL, that is). You can either type ‘nm-applet‘ on the command line or you can switch to using nm-applet instead of nm-tray by deselecting nm-tray in LXQt ‘Application Menu’ > ‘Preferences’ > ‘LXQt Settings’ > ‘Session Settings’ > ‘Autostart’ and adding nm-applet to the Autostart list. See Lubuntu Manual Appendix G Advanced Networking for further details. As already mentioned, in my situation the client is using OpenSSL 3.x.x and the server is using OpenSSL 1.x.x so the VPN connection still times out, therefore the work-around is still to launch openvpn from the command line:

user $ openvpn --conf bsf1.ovpn

To summarise my situation:

On my smartphone running Android 13 I simply use the OpenVPN client app for Android with the original client.ovpn configuration file (named ‘bsf1.ovpn‘ in my case) in order to connect to the VPN server on the remote server running OpenSSL 1.0.2l.

In Gentoo Linux currently running OpenSSL 3.0.10, I have to edit the original client.ovpn configuration file and add three lines, then launch the openvpn client from the command line in a terminal window in order to connect to the VPN server on the remote server running OpenSSL 1.0.2l.

In Lubuntu 22.04 currently running OpenSSL 3.0.2, I have to edit the original client.ovpn configuration file and add two lines, then launch the openvpn client from the command line in a terminal window in order to connect to the VPN server on the remote server running OpenSSL 1.0.2l.

The bottom line is: To avoid problems, check you have the same version of OpenSSL installed in the client and server devices when using OpenVPN.

Prevent Lubuntu 22.04 (SDDM and LXQt) from leaving an external drive mounted incorrectly for other users

An external USB disk drive is connected permanently to my family’s PC that currently has Lubuntu 22.04 installed. There are several user accounts on this multi-user single-seat machine. If a user does not unmount the external drive before logging out, when another user logs in, the external drive is still mounted with the priviledges of the previous user. In the days when Lubuntu used LightDM and LXDE, I devised a scheme to unmount automatically the external drive when each user logged out (see an earlier post). However, that method is no longer possible now Lubuntu no longer uses LightDM. Therefore I devised a different scheme. This time, the external drive is unmounted automatically every time a user logs in, and udisks2 automatically mounts it for the current user. Below I explain the new scheme. In the example below the external USB drive happens to be an NTFS drive and have the label ‘FREECOM HDD’. The machine actually has several user accounts but, for the sake of brevity, the commands for only two users are shown. All the steps shown below are performed by the account holder with the ability to use the sudo command to get superuser priviledges.

1. Create a root script to unmount the external USB drive

$ sudo nano /usr/local/sbin/unmount_FREECOM_HDD.sh

The file contains the following lines:

#!/bin/bash
# Unmount the external USB HDD if mounted with another username in the path:
umount /media/*/FREECOM\ HDD 2>/dev/null

2. Make sure the script has the correct priviledges

$ sudo chmod 755 /usr/local/sbin/unmount_FREECOM_HDD.sh

3. Give each user permission to use the sudo command to run the abovementioned script

$ sudo visudo -f /etc/sudoers.d/unmount_FREECOM_HDD

Add a line for each user:

fitzcarraldo ALL=NOPASSWD: /usr/local/sbin/unmount_FREECOM_HDD.sh
molly ALL=NOPASSWD: /usr/local/sbin/unmount_FREECOM_HDD.sh

4. Create an autostart Desktop Configuration File for each user

$ sudo nano "/home/fitzcarraldo/.config/autostart/Unmount FREECOM HDD.desktop"
$ sudo nano "/home/molly/.config/autostart/Unmount FREECOM HDD.desktop"

Each user’s autostart file should contain the following:

[Desktop Entry]
Exec=sudo /usr/local/sbin/unmount_FREECOM_HDD.sh
Name=Unmount FREECOM HDD
OnlyShowIn=LXQt;
Type=Application
Version=1.0

Make sure the autostart files have the correct ownership and priviledges

$ sudo chown fitzcarraldo:fitzcarraldo "/home/fitzcarraldo/.config/autostart/Unmount FREECOM HDD.desktop"
$ sudo chmod 664 "/home/fitzcarraldo/.config/autostart/Unmount FREECOM HDD.desktop"
$ sudo chown molly:molly "/home/molly/.config/autostart/Unmount FREECOM HDD.desktop"
$ sudo chmod 664 "/home/molly/.config/autostart/Unmount FREECOM HDD.desktop"

(If each user logs in to their LXQt Desktop, clicks on the Application Menu icon and selects ‘Preferences’ > ‘LXQt Settings’ > ‘Session Settings’ and clicks on Autostart’, there should be the ticked entry ‘Unmount FREECOM HDD’ in the ‘LXQt Autostart’ section.)

5. Reboot and the scheme should take effect.

Work-around if movie subtitles restart after the final subtitle is displayed

If I’m watching movies in a language I don’t understand, I want subtitles. On my computers this is possible as long as there is a subtitles file with the name suffix .srt and the same prefix name as the .mp4 video file in the same directory. I usually prefer to view movies on my TV with a bigger screen, so I copy the movie to a HDD that is normally connected to my TV (a FINLUX model 43-FUD-8020). However, the built-in media player in the TV does not show the subtitles in the .srt file, even when it is in the same directory as the .mp4 file. Therefore I use the MKVToolNix utility mkvmerge to put the movie and subtitles into a Matroska multimedia container (.mkv file), and the TV’s media player can play these .mkv files and does display the subtitles. In fact, so can my laptops and desktop running Linux (I have not tried on a machine running Windows 10, but I assume Windows 10 would have no trouble either).

To install in Lubuntu 20.10:

user $ sudo apt install mkvtoolnix

To install in Gentoo Linux:

root # emerge mkvtoolnix

To create a Matroska file containing the movie plus subtitles:

user $ mkvmerge -o movie_with_subtitles.mkv movie_without_subtitles.mp4 subtitles.srt

Normally the last subtitle in a movie does not occur at the very end of the movie. For example, there could be action without dialogue at the end of the movie, and/or final credits without dialogue. The media players on my laptops and desktop running Linux display the last subtitle and play the rest of the movie in the Matroska container as expected. However, the media player in my FINLUX TV displays the last subtitle and then displays the subtitles from the beginning again, at breakneck speed. Annoying to say the least. As the problem does not occur on my laptops and desktop with the same .mkv file, I assume the problem lies with the media player in the TV.

At first I suspected that the .srt file was the cause, but it correctly uses UTF-8 encoding and the syntax of the contents is correct. Anyway, just to be sure I ran it through an online cleaner for .srt files and re-generated the .mkv file, but that made no difference on the TV. Since there is no problem playing the .mkv file on my computers, I can only assume the TV’s media player is indeed at fault. I cannot do anything about the TV’s media player, so I came up with an acceptable work-around: I added a dummy subtitle at the end of the .srt file that is set to be displayed at the very end of the movie. For example, let’s say the movie duration is two hours, 12 minutes and twenty-two seconds but the last subtitle is at 01:56:38,201:

188
01:56:38,201 --> 01:56:40,286
The end justifies the means.

I edited the file and added a dummy subtitle at the end:

188
01:56:38,201 --> 01:56:40,286
The end justifies the means.

189
02:12:19,001 --> 02:12:21,999
THE END.

I then re-generated the .mkv file using the mkvmerge command and, lo and behold, after the subtitle displayed between at 01:56:38,201 and 01:56:40,286 the TV no longer displays any more subtitles until the very end of the movie when it displays ‘THE END’ and the video ends. Actually, in reality the movie must be very slightly longer than 02:12:21,999 because, after displaying ‘THE END’, the first six subtitles in the subtitle file are displayed in rapid succession before the media player stops playing, but that is no big deal.

I searched the Web quite a lot and was unable to find any mention of this particular problem, so I am posting my work-around here just in case it helps someone else experiencing the same problem.

Browsing a WebDAV share in Linux and Windows 10

In this post I explain how I configured my machines running two Linux distributions (Gentoo Linux and Lubuntu 20.10) and my Windows 10 test machine to enable me to browse a shared folder on my file server (running ownCloud, in my case) that uses the WebDAV protocol. I cover two options for configuring Linux to browse WebDAV shares. Further options exist in Linux, but the two methods I give here are fine for my purposes.

I installed ownCloud on my Linux server in a slightly different way to the method in the ownCloud installation manual, and my examples in this post use the URI https://fitzcarraldo.ddns.net/owncloud/remote.php/webdav rather than the usual https://fitzcarraldo.ddns.net/remote.php/webdav for ownCloud, so replace the URI in my examples with the appropriate URI in your case. The username of the user account on each client machine is ‘fitz’, and the ownCloud username (davusername) on the server is ‘bsf’. Obviously replace those with the usernames in your case.

PART 1 – LINUX

Unless I mention the distribution explicitly, the following steps apply to both Linux distributions. As my Gentoo Linux installations use KDE, the steps for Gentoo Linux assume the file manager is Dolphin. My Lubuntu installation uses the file manager PCManFM-Qt.

1. Install davfs2 if it is not already installed

Gentoo Linux:

root # emerge davfs2

That command installs three packages:

acct-group/davfs2
acct-user/davfs2
net-fs/davfs2

Lubuntu 20.10:

user $ sudo apt install davfs2

2. Lubuntu 20.10: Allow mounting by non-root users

user $ sudo dpkg-reconfigure davfs2

   Package configuration
   
    ┌──────────────────────────────────────────┤ Configuring davfs2 ├───────────────────────────────────────────┐
    │                                                                                                           │
    │ The file /sbin/mount.davfs must have the SUID bit set if you want to allow unprivileged (non-root) users  │
    │ to mount WebDAV resources.                                                                                │
    │                                                                                                           │
    │ If you do not choose this option, only root will be allowed to mount WebDAV resources. This can later be  │
    │ changed by running 'dpkg-reconfigure davfs2'.                                                             │
    │                                                                                                           │
    │ Should unprivileged users be allowed to mount WebDAV resources?                                           │
    │                                                                                                           │
    │                               <Yes>                                  <No>                                 │
    │                                                                                                           │
    └───────────────────────────────────────────────────────────────────────────────────────────────────────────┘

(Do not do anything in Gentoo Linux; the SUID bit should be set automatically.)

3. Check the SUID bit has been set (notice the ‘s’ in the file’s permissions)

Gentoo Linux:

user $ ls -la /sbin/mount.davfs
lrwxrwxrwx 1 root root 21 Sep 25 23:03 /sbin/mount.davfs -> /usr/sbin/mount.davfs
user $ ls -la /usr/sbin/mount.davfs
-rws--x--x 1 root root 130752 Sep 25 23:03 /usr/sbin/mount.davfs

If the SUID bit has not be set automatically, you can do it manually:

user $ sudo chmod u+s /usr/sbin/mount.davfs

Lubuntu 20.10:

user $ ls -la /sbin/mount.davfs
-rwsr-xr-x 1 root root 137464 Aug  8  2020 /sbin/mount.davfs

4. Add the user to the davfs2 group

user $ sudo usermod -aG davfs2 fitz

Logout and login again and check the user is a member of the group:

user $ groups | grep -q davfs2 && echo "OK"
OK

5. Leave the lines in the following files commented out (i.e. accept the defaults)

/etc/davfs2/davfs2.conf (system-wide)

~/.davfs2/davfs2.conf (user-specific)

6. Option 1 (simplest!) – Enter the URI in the file manager and bookmark it

6.1 Gentoo Linux with KDE

Enter the following URI on the Dolphin file manager’s address line and press Enter:

webdavs://fitzcarraldo.ddns.net/owncloud/remote.php/webdav

You will be prompted to enter the username and password for the WebDAV share.

Select ‘File’ > ‘Add to Places’ in Dolphin to bookmark the share. From then on, you can browse the share by clicking on the share in the Remote section in Dolphin’s Places pane. You can rename the bookmark if you wish (right-click and select ‘Edit…’).

Another way to do this in KDE is as follows:

1. click on ‘Network’ in the Places pane;
2. click on ‘Add Network Folder’ next to the address bar;
3. select ‘WebFolder (webdav)’ and click ‘Next’;
4. enter the fields as follows:
   • Name: webdav
   • User: bsf
   • Server: fitzcarraldo.ddns.net
   • Port: 443 (I use Port 443 but you may be using a different port)
   • Folder: owncloud/remote.php/webdav
5. select ‘Create an icon for this folder’ and ‘Use encryption’;
6. click ‘Save & Connect’;
7. right-click on the webdav icon in the main Dolphin pane and select ‘Add to Places’.

6.2 Lubuntu 20.10

Enter the following URI on the PCManFM-Qt file manager’s address line and press Enter:

davs://fitzcarraldo.ddns.net/owncloud/remote.php/webdav

You will be prompted to enter the username and password for the WebDAV share.

Select ‘Bookmarks’ > ‘Add to Bookmarks’ in PCManFM-Qt to bookmark the share. From then on, you can browse the share by clicking on the share in the Bookmarks section in PCManFM-Qt’s Lists pane. You can rename the bookmark if you wish (Bookmarks > Edit Bookmarks).

7. Option 2 – Assign a mountpoint at boot:

Add the following credentials line in the file ~/.davfs2/secrets:

https://fitzcarraldo.ddns.net/owncloud/remote.php/webdav <davusername> <davpassword>

and set the file permissions as follows:

user $ chmod 600 ~/.davfs2/secrets

Create a user directory onto which to mount the share:

user $ mkdir ~/webdav

Add a line in /etc/fstab to map the WebDAV share onto that directory at boot:

# <file system>                                            <mount point>       <type>  <options>        <dump>  <pass>
https://fitzcarraldo.ddns.net/owncloud/remote.php/webdav   /home/fitz/webdav   davfs   noauto,user,rw   0       0

The options ‘auto‘ and ‘_netdev‘ do not mount the WebDAV share automatically at boot in my installations; I am prompted to enter the davuser and davpassword manually early in the boot process if I include those options. To avoid the latter I use the ‘noauto‘ option and do not bother including the ‘_netdev‘ option. There are ways to mount a WebDAV share automatically at boot whether your installation uses systemd, OpenRC or other rc systems. Nevertheless I prefer the WebDAV share not to be mounted auomatically at boot, especially in the case of my laptops.

Reboot to check everything works.

Lubuntu 20.10:

The share will be listed as ‘webdav’ (unmounted) in the Devices section under Lists in PCManFM-Qt. You can click on the unmounted share to mount it, and click on the Unmount icon to unmount it. Everything works as expected.

Gentoo Linux with KDE:

The share is not listed in the Places pane in Dolphin but the share can be mounted manually from the command line as follows:

user $ mount ~/webdav
/sbin/mount.davfs: warning: the server does not support locks

(The ‘user‘ option in /etc/fstab allows the non-root user to mount the share.)

The main pane displaying the contents of ~/webdav/ will only be populated with the contents of the remote folder after the share is mounted.

The share is browsable in Dolphin. I can perform all file and folder operations in KDE apart from one thing: I cannot copy files to the server (neither from the local machine nor from the server); Dolphin displays messages such as ‘There is not enough space on the disk to write file:///home/fitz/testfile.txt’. I suspect the problem is with KDE, because I can copy files to and on the share by using the command line (for example the commands ‘cp ~/test1.txt ~/webdav/‘ and ‘cp ~/webdav/test2.txt ~/webdav/test3.txt‘ work fine). I have yet to find a solution to this issue, so I use Option 1 for Gentoo Linux running KDE, which works fine. To create a bookmark in Dolphin’s Places pane, browse the share and select ‘File’ > ‘Add to Places’.
 
PART 2 – WINDOWS 10

There is a Map Network Drive Wizard, but it is not as straightforward for WebDAV shares as it is with SMB shares. See the thread Cannot connect to webdav service for the type of behaviour I experienced, althought in my case I could rarely establish a connection using either ‘Map network drive’ or ‘Add a network location’, and the mapping was always lost if I logged out or rebooted, despite selecting ‘Reconnect at sign-in’. I then discovered several invalid URIs in Registry keys. Presumably these were left in the Registry after my various unsuccessful configuration attempts using the wizard. To finally succeed in mapping the ownCloud WebDAV shared folder I had to search for the string ‘fitzcarraldo.ddns.net’ in the Registry (see Steps 1 & 2 below for how to open the Registry) and delete any existing strings similar or identical to ‘https://fitzcarraldo.ddns.net/ownloud/remote.php/webdav‘, as they seemed to interfere with successful mapping of the network directory.

After making sure the Registry no longer contained any incorrect-looking WebDAV URIs for my ownCloud server, I used the following steps:

1. Right-click on Windows’ Start Menu icon on the left of the Task Bar and select ‘Run’.
2. Enter ‘regedit’ in the Open box and click ‘OK’.
3. Select Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
4. If the value in BasicAuthLevel is not already 2, change it to 2.
5. In the ‘Type here to search’ box on the Task Bar, enter ‘Services’ and press Enter.
6. Click ‘Services App’.
7. Scroll down to ‘WebClient’ in the Services window.
8. Right-click ‘WebClient’ and select ‘Properties’.
9. If ‘Startup type’ is not already set to ‘Automatic’, change it to ‘Automatic’ and click ‘Apply’.
10. Launch File Explorer.
11. Right-click ‘This PC’ and select ‘Map network drive…’.
12. Select the drive letter (default is Z:).
13. In the Folder box enter \\fitzcarraldo.ddns.net@SSL\owncloud\remote.php\webdav and make sure only ‘Reconnect at sign-in’ is ticked.
14. Click ‘Finish’.
15. A network icon and the label ‘webdav (\\fitzcarraldo.ddns.net@SSL\owncloud\remote.php) (Z:)’ should appear under ‘My PC’. Clicking that icon displays the contents of the shared folder of my ownCloud account on my server.

The only Registry entries containing ‘fitzcarraldo.ddns.net’ found by ‘Edit’ > ‘Find…’ are now the following:

Computer\HKEY_CURRENT_USER\Network\Z
RemotePath     REG_SZ     \\fitzcarraldo.ddns.net@SSL\owncloud\remote.php\webdav

Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Map Network Drive MRU
a     REG_SZ     \\fitzcarraldo.ddns.net@SSL\owncloud\remote.php\webdav

Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\##fitzcarraldo.ddns.net@SSL#owncloud#remote.php#webdav
LabelFromReg     REG_SZ     webdav (\\fitzcarraldo.ddns.net@SSL\owncloud\remote.php)

Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\PublishingWizard\AddNetworkPlace\AddNetPlace\LocationMRU
a     REG_SZ     https://fitzcarraldo.ddns.net/owncloud/remote.php/webdav

Computer\HKEY_USERS\S-1-5-21-4039722433-590489090-552845671-1001\Network\Z
RemotePath     REG_SZ     \\fitzcarraldo.ddns.net@SSL\owncloud\remote.php\webdav

Computer\HKEY_USERS\S-1-5-21-4039722433-590489090-552845671-1001\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Map Network Drive MRU
a     REG_SZ     \\fitzcarraldo.ddns.net@SSL\owncloud\remote.php\webdav

Computer\HKEY_USERS\S-1-5-21-4039722433-590489090-552845671-1001\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\##fitzcarraldo.ddns.net@SSL#owncloud#remote.php#webdav
LabelFromReg     REG_SZ     webdav (\\fitzcarraldo.ddns.net@SSL\owncloud\remote.php)

Computer\HKEY_USERS\S-1-5-21-4039722433-590489090-552845671-1001\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\PublishingWizard\AddNetworkPlace\AddNetPlace\LocationMRU
a     REG_SZ     https://fitzcarraldo.ddns.net/owncloud/remote.php/webdav

 
CONCLUSION

There you have it. I can browse my ownCloud user account folders on my server from my machines running Linux and from my test machine running Windows 10.

Installing and configuring davfs2 in Linux, and using Option 1 to browse a WebDAV share is very easy in both Gentoo Linux running KDE and in Lubuntu 20.10. Using Option 2 is also very easy in Lubuntu 20.10 but is not easy in Gentoo Linux running KDE, and I still need to find out if there is a better approach for Option 2 in Gentoo Linux running KDE.

I found Windows 10 the most problematic, despite the apparent simplicity of the ‘Map network drive’ and ‘Add a network location’ wizards. I discovered that, if I didn’t get the format of the URI correct the first time, Windows 10 would leave ‘cruft’ in the Registry that apparently prevented further mapping attempts from working properly and consistently.

Anyway, everything works the way I want and I hope this post is of some help to others wanting to browse a share using WebDAV, be that a folder in ownCloud, Nextcloud or any other network service requiring the WebDAV protocol.

croc – another file transfer method

I have lost count of the number of times I have had to send a large file to someone at work, usually in a hurry. I’ve used Dropbox, ownCloud, Firefox Send (no longer available) etc. Transferring large files became a bit easier when e-mail service providers increased the size limit for attachments, but that is still not a solution for very large files. The xkcd cartoon FILE TRANSFER sums up the situation nicely.

I recently discovered the command line utility croc, which the author claims is a way to ‘easily and securely transfer stuff from one computer to another.’ I thought I’d give it a try, if only to have another tool to fall back on in an emergency. It does rely on both ends having croc installed, but hopefully that should not be a show-stopper as croc is available for Linux, Windows, macOS and BSD. To quote the author:

croc differs from a utility like scp because it doesn’t require any two computers to have enabled port-forwarding. Instead, croc will uses a relay – a temporary server setup locally (if both computers are on lan) or publicly (default is at croc4.schollz.com). Any two computers can connect to the relay, and after securing their channel with PAKE [password authenticated key exchange], they can transfer encrypted metadata and data through the relay. The relay works by first having the computers communicate the PAKE protocol via websockets, and then exchanging encrypted metadata, and then stapling the TCP connections directly so that they can transfer directly.

So, to use croc you will be dependent on the public relay provided by the author unless you set up your own relay (instructions are provided in the author’s original 2018 blog post introducing croc – see link above – and in various third-party articles about croc, such as ‘Securely Transfer Files and Folders Between Computers Using Croc‘ and ‘Transfer Files And Folders Between Computers With Croc‘).

Anyway, I installed croc in Lubuntu and Gentoo Linux from the author’s GitHub repository and indeed it is easy to use and works fine. The binary releases for the various OSs and Linux distributions can be found on the Releases page of the GitHub repository or via the OS package manager.

Lubuntu 20.10:

user $ wget https://github.com/schollz/croc/releases/download/v9.1.6/croc_9.1.6_Linux-64bit.deb
user $ sudo dpkg -i croc_9.1.6_Linux-64bit.deb

Gentoo Linux:

root # emerge net-misc/croc

(Note that croc ebuilds are not currently marked as Stable in the Gentoo Linux Portage tree, so you’ll have to unmask them by keyword if you are using the Stable branch.)

Termux:

I even installed croc in Termux on my Samsung Galaxy Note 20 Ultra 5G, and it works in Android too:

$ pkg install croc

Other OSs and other Linux distributions:

See the instructions in the README file online.

Using croc

Using croc is as simple as entering a command on one computer, informing (via e-mail, telephone, SMS, Signal or other social media) the person using the other computer of the command to use, and entering that command on the other computer. For example:

Sender

user $ croc send Documents/flight-times.ods
Sending 'flight-times.ods' (16.6 kB)
Code is: 8878-salary-courage-roger
On the other computer run

croc 8878-salary-courage-roger

Receiver

user $ croc 8878-salary-courage-roger
Accept 'flight-times.ods' (16.6 kB)? (Y/n) 

If the receiving user then enters ‘Y’, the sending user sees something similar to this:

user $ croc send Documents/flight-times.ods
Sending 'flight-times.ods' (16.6 kB)
Code is: 8878-salary-courage-roger
On the other computer run

croc 8878-salary-courage-roger

Sending (->192.168.1.74:60740)
 100% |████████████████████| (17/17 kB, 10.918 MB/s)
user $ 

and the receiving user sees something similar to this:

user $ croc 8878-salary-courage-roger
Accept 'flight-times.ods' (16.6 kB)? (Y/n) Y

Receiving (<-[::1]:39442)
 100% |████████████████████| (17/17 kB, 3.989 MB/s)
user $ 

The observant reader will notice that the above example shows a file being transferred on the same computer. When transferred between different computers the IP addresses of each computer will be displayed instead. I have used croc to transfer files between different computers on my home network (I would normally just use my NAS for this, though), between remote computers on the Internet, and between my computers and my phone via mobile broadband, and croc works in all cases.

I have not mentioned all croc’s features. I’ll leave you to read up on croc in more detail in the links I’ve given above. It looks like it might be a useful tool to have installed.

Using adb tools in Linux to remove bloatware from my Samsung Galaxy Note 20 Ultra

Samsung included a lot of bloatware on my Galaxy Note 20 Ultra 5G, and it is not possible to uninstall it using Play Store. However, it is possible to remove this stuff using adb tools. I got rid of the bloatware I don’t want very easily using the Linux version of the adb tools.

I have never had a Facebook account and never will, so I decided to remove all trace of it as follows:

1. Installed adb tools

In Lubuntu 20.10:

user $ sudo apt install android-tools-adb

In Gentoo Linux:

root # emerge dev-util/android-tools

2. Enabled ‘Developer Options’ on the phone

‘Settings’ > ‘About Phone’ > ‘Software Information’ and quickly tapped 7 times on ‘Build number’.

3. Enabled USB Debugging on the phone

‘Settings’ > ‘Developer options’, scrolled down and tapped on ‘USB debugging’.

4. Launched adb

user $ adb start-server
* daemon not running; starting now at tcp:5037
* daemon started successfully

5. Connected the phone to the computer using the USB cable

A few prompts on the phone asked whether or not I wanted to allow USB debugging. Tapped ‘Always allow from this computer’ and tapped ‘OK’.

6. Uninstalled Facebook

The packages I needed to uninstall were:

com.facebook.appmanager
com.facebook.katana
com.facebook.services
com.facebook.system

First I tried to uninstall with the ‘-k‘ option:

user $ adb uninstall -k --user 0 com.facebook.appmanager
The -k option uninstalls the application while retaining the data/cache.
At the moment, there is no way to remove the remaining data.
You will have to reinstall the application with the same signature, and fully uninstall it.
If you truly wish to continue, execute 'adb shell cmd package uninstall -k'.

See ‘Difference between pm clear and pm uninstall -k on Android‘

I have never been a member of Facebook and never will, so I dispensed with the ‘-k‘ option and entered the following commands:

user $ adb uninstall --user 0 com.facebook.appmanager
Success
user $ adb uninstall --user 0 com.facebook.katana
Success
user $ adb uninstall --user 0 com.facebook.services
Success
user $ adb uninstall --user 0 com.facebook.system
Success

I didn’t want the LinkedIn, Samsung Global Goals and Spotify apps either, so I uninstalled those too:

user $ adb uninstall --user 0 com.linkedin.android
Success
user $ adb uninstall --user 0 com.samsung.sree
Success
user $ adb uninstall --user 0 com.spotify.music
Success

7. Stopped the adb server on the computer

user $ adb kill-server

8. Unplugged the phone from the computer.

That’s it.

In order to disable the apps using this method, you will need to know the exact package name of the app you want to get rid of. For this, use Play Store and install App Inspector (there are several apps with this name in Play Store; I installed the app by Projectoria Ltd but the others look OK too). Launch App Inspector and you can find the package name under the name of the app. This starts with a ‘com‘ or ‘net‘ followed by words separated by dots.

For example, App Inspector shows the package name for LinkedIn as ‘com.linkedin.android‘.

Some useful links:

• How to install and setup ADB tools on Linux
• How To Remove Bloatware on Samsung Galaxy Note 20 and Improve Performance
• WARNING: Do *NOT* delete all the apps in this list
• Disable Bloatware on Your Galaxy Note 20 for Free Without Root
• How to Remove Samsung Bloatware without Root (ADB)

To get a list of all the packages installed on my phone:

user $ adb shell pm list packages

To get a list of system apps only:

user $ adb shell pm list packages -s

To get a list of only Samsung packages:

user $ adb shell pm list packages | grep samsung

To search for e.g. facebook packages:

user $ adb shell pm list packages | grep facebook

(Returns nothing now, as I already deleted all the Facebook packages. Yay!)

To search for other packages, e.g.:

user $ adb shell pm list packages | grep kids
package:com.samsung.android.kidsinstaller
package:com.sec.android.app.kidshome

Resurrecting my Iomega Zip 100 parallel-port drive – Linux comes to the rescue

Top view of Z100P2 drive with 100 MB Zip disk in front.

Z100P2 drive with disk inserted.

Rear sockets of Z100P2 drive.

Back in 1998 I purchased what was then a state-of-the-art storage medium: an external Iomega Zip 100 drive, which used removable 100 MB ‘SuperFloppy’ disks. Until 2002 I backed up my important files on removable Zip 100 MB disks. Over several years in the 1990s Iomega released various models of the Zip 100 MB drive: internal SCSI; internal IDE; internal ATAPI; external DB-25 IEEE 1284 parallel port; external USB 1.1. I bought the external DB-25 IEEE 1284 parallel port model Z100P2. When affordable CD drives and external hard disk drives started to appear I began using those for backups instead, and the Zip drive and a box full of Zip 100 MB disks had been gathering dust on a shelf at home since I stopped using them in 2002.

Now, I was fairly sure I had copied all the files off those Zip disks all those years ago, but recently I wanted to check the contents and then wipe the disks prior to disposing of them and the drive. The trouble was, I have not owned a computer with a legacy parallel port for many years. This is the story of how I managed to use the Zip 100 drive again after a hiatus of some nineteen years.

Notice that the drive has a second DB-25 port with the icon of a printer above it. That socket is to allow a legacy parallel port printer to be connected (‘daisy chained’) to the computer at the same time as the Zip 100 drive. I have not owned a parallel port printer for many years, so that port is of no interest to me.

By the way, the Iomega Zip 100 drive gained rather a bad reputation because of the so-called click of death, although Iomega stated that it affected less than 0.5 percent of all Jaz and Zip drives. I never experienced this problem with my Zip 100 drive and it is still working.

PART 1 – HARDWARE

Power supply for Z100P2

When I purchased it in 1998, the Zip 100 drive was supplied with a chunky and rather heavy 240 VAC to 5 VDC PSU. However, I gave that away several years ago with an old 250 MB external USB HDD that required a 5 VDC power supply. So my first job was to get a 5 VDC supply for the Zip 100 drive. I decided to buy a USB-to-barrel-plug cable to power the Zip drive from a USB port on a computer. So I purchased a ‘USB to 5V DC power cable compatible with the Iomega Z100P2 ZIP drive’ from Amazon. The LEDs on the drive lit up and the drive briefly made the expected noise when I connected the drive to a computer using this power cable, so I was making progress. If a computer happens to have USB Type-A ports, this turns out to be a much neater approach than having to use a 5 VDC PSU.

5 Volts DC power socket on Z100P2 and barrel connector of the cable that is connected to the computer via USB Type-A at the other end.

 
Failed first attempt: USB to legacy parallel port printer adapters do NOT work with parallel Zip drives!

None of my laptops and desktop machines have the legacy DB-25 parallel port that the Z100P2 drive requires. No problem, I thought to myself, I’ll just buy a ‘USB to Printer DB25 25-Pin Parallel Port Cable Adapter’ – there are umpteen of these adapters available on eBay and Amazon. It wasn’t expensive, but I found out the hard way that these cable adapters usually work with parallel printers but definitely do not work with Iomega Zip 100 drives. So I needed to do one of the following:

• get a parallel printer interface card for a PCIe slot in my modern desktop machines – and hope it would work with a Z100P2 drive;
• get a legacy computer with a bidirectional parallel port with a DB-25 socket;
• get a legacy computer with a PCI slot into which I could insert a legacy parallel printer PCI interface card (assuming I could get hold of one).

Computer with legacy parallel port

I searched eBay and found a second-hand Dell OptiPlex 780 SFF (Small Form Factor) with a legacy DB-25 parallel port (connected to the motherboard rather than to a card in one of its PCI slots), Intel Pentium E5800 CPU (3.20 GHz, 800 Mz FSB), 4 GB of PC3-10600U (1333 MHz) DDR3 DIMM memory and Windows 10 Pro installed with a valid licence. It also has plenty of USB 2.0 Type-A ports, convenient for the USB-to-barrel-plug cable I bought to power the Z100P2 drive. The price was very reasonable indeed, so I bought it in the hope that it would be usable. The vendor assured me that Windows 10 detected the parallel port and no errors were reported, but the vendor had no legacy devices (e.g. parallel port printer) with which to actually test the port. Anyway, as it was so cheap I took a gamble and purchased it, although my research on the Web had already indicated that Windows 10 does not support parallel port Iomega Zip drives. I was thinking I could either try using a virtual machine or just wipe Windows 10 and install Linux on the machine.

The FSB speed of the legacy CPU actually limits the memory speed to 800 MHz, but performance is not too bad. I actually replaced the 4 GB of PC3-10600U memory with 8 GB of PC3-12800U (1600 MHz) memory (Crucial CT51264BD160B.C16FED2) which I purchased for a very good price on eBay, although upgrading to 8 GB of memory was not necessary for the purpose of getting the Zip 100 drive working. I decided to increase the memory because the machine is in a nice condition so I will keep it for future projects, which might need more memory.

By the way, the Dell documentation for the OptiPlex 780 SFF that I downloaded from Dell’s Web site states that the machine can only use 1066 MHz memory modules or 1333 MHz memory modules, and the 1333 MHz memory modules would only be able to have a speed of 1066 MHz. What is not obvious is that the documentation assumes that one of the E6xxx series or E7xxx series Wolfdale-3M CPUs (45 nm) is installed, as the speed of the FSB (Front Side Bus) of those CPUs is 1066 MHz. The earlier Wolfdale-3M CPUs which are installed in some OptiPlex 780 SFF machines have a FSB speed of 800 MHz, so even 1066 MHz memory modules are only going to have a speed of 800 MHz in those machines. The Wolfdale-3M CPU in my Dell machine is an E5800, which has a FSB speed of 800 MHz, so the memory speed is limited to 800 MHz (as confirmed on the BIOS System Setup screen, by the CPU-Z utility program running in Windows 10 (2 x 399.0 MHz), and by the Linux commands ‘sudo dmidecode --type 17‘ and ‘sudo lshw -short -C memory‘). The Crucial CT51264BD160B.C16FED2 PC3-12800 modules work fine in the machine, albeit limited to 800 MHz due to the CPU bus speed. On another note, if you happen to be looking for memory for a Dell OptiPlex 780 SFF, do NOT buy CT51264BD160BJ modules: the ‘J’ stands for ‘high-density’, and high-density modules do not work in this model.

Parallel port settings in the PC BIOS

The refurbished Dell OptiPlex 780 SFF has the following user-selectable options:

1. Disable = Port is disabled
2. AT = Port is configured for IBM AT compatibility
3. PS/2 = Port is configured for IBM PS/2 compatibility
4. EPP = Enhanced Parallel Port protocol
5. ECP No DMA = Extended Capability Port protocol with no DMA
6. ECP DMA 1 = Extended Capability Port protocol with DMA 1
7. ECP DMA 3 = Extended Capability Port protocol with DMA 3

The BIOS had option ‘PS/2’ selected when I received the machine, which I eventually changed to ‘ECP No DMA’ but I think that was unnecessary.

The BIOS also had the Parallel Port Address set to 378h when I received it, and I left it as that.

Data connection

Fortunately I still had the original parallel cable to connect the Zip drive to a DB-25 parallel port on a computer.

Z100P2 end of cable connected to computer parallel port.

Rear of legacy Dell PC with Z100P2 cable connected to the parallel port, and USB-to-barrel-plug power cable connected to a USB port.

PART 2 – SOFTWARE

First attempt – Failure: Windows XP in a VirtualBox virtual machine

My original intention was to wipe Windows 10 from the Dell machine and install Linux to see if I could get Linux to access the Zip drive. But, on second thoughts, I decided I might have a better chance in Windows because my research on the Web had already indicated that several people had successfully used Iomega Zip 100 parallel-port drives with Windows XP running in a virtual machine under Windows 10. I carefully followed a detailed article on how to do this using VirtualBox (How to use iomega zip 100 with parallel port on a windows 10 computer (so long as you have a free PCI slot)), but the Zip drive would not work with the Dell machine. I tried every BIOS option for the parallel port; I tried allowing Windows XP to install the driver; I installed the last official Iomega issue of the driver for Windows XP. Nothing worked.

Second attempt – Failure: Lubuntu 20.10 in a VirtualBox virtual machine

Then I decided to try installing Linux in a VirtualBox virtual machine under Windows 10. I chose Lubuntu 20.10 because it already has the necessary ppa (for older Zip parallel-port drives like mine) and the imm (for later versions of Zip 100 parallel-port drives than mine) modules built and either could simply be loaded from the command line. But that couldn’t access the drive either. Again, I tried without success every BIOS option for the parallel port.

Third attempt – Success: Live Lubuntu 20.10 on a USB pendrive

I was resigned to wiping Windows 10 and installing a Linux distribution when I had a brainwave: Why not try a Live Linux distribution? I used the mkusb utility to create a persistent installation of Live Lubuntu 20.10 on a USB pendrive (it had to use PC BIOS, as the legacy Dell machine does not support UEFI), booted it and used the command modprobe ppa to load the ppa parallel port driver. Shazam! The drive became device /dev/sdc4 and was auto-mounted as ‘ZIP-100’ in the LXQt file manager window. I can browse all the files on the 100 MB ZIP disks. It’s fast, too. I wish I’d thought of trying that first. I could have reformatted the disks with a Linux filesystem (ext4 or whatever) if I wanted to do that.

I then downloaded from a Debian amd64 repository the binary package for a 1996 Linux GUI utility named ‘jaZip‘ that someone named Jarrod Smith (thank you!) wrote in 1996 for Iomega Jaz and Zip drives, and I installed it easily in the Live Lubuntu 20.10 environment. It works perfectly, allowing me to mount, unmount, lock, unlock and eject Zip 100 MB disks. Linux came to the rescue again. I’m chuffed. Below are details of the steps I took to create a persistent Live USB pendrive with Lubuntu 20.10 with the ability to use my Iomega Z100P2 drive connected to the Dell OptiPlex 780 SFF PC.

By the way, a persistent Live Linux USB pendrive is not essential, it just means you don’t have to manually load the ppa module, re-install jaZip and configure it every time you boot the Live Linux environment.

1. Download the ISO of Lubuntu 20.10 from the official Lubuntu Web site.

2. Use the procedure in the following ‘How To’ article to create a persistent Live pendrive of Lubuntu 20.10 by using the utility mkusb:

Create a persistent Ubuntu USB which boots to RAM

The mkusb windows in that 2016 article are a bit different to those in the version of mkusb (12.3.9) that was installed by following the procedure, but it is fairly obvious what to do. Select the old user interface (Option e: Old User Interface). There is no need to perform the steps in ‘Extra: Boot the Live USB to RAM’ because it is now done automatically for you and added to the GRUB boot menu as an additional option.

3. Once I had created the persistent Live pendrive, I booted it and performed the installation procedure for jaZip, and configured the persistent Live installation. The console output for all these steps is shown below:

lubuntu@lubuntu:~$ sudo apt install libforms2
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following NEW packages will be installed:
  libforms2
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 327 kB of archives.
After this operation, 975 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu groovy/universe amd64 libforms2 amd64 1.2.3-1.4 [327 kB]
Fetched 327 kB in 0s (807 kB/s)  
Selecting previously unselected package libforms2.
(Reading database ... 240052 files and directories currently installed.)
Preparing to unpack .../libforms2_1.2.3-1.4_amd64.deb ...
Unpacking libforms2 (1.2.3-1.4) ...
Setting up libforms2 (1.2.3-1.4) ...
Processing triggers for libc-bin (2.32-0ubuntu3) ...
lubuntu@lubuntu:~$ cd ~/Downloads
lubuntu@lubuntu:~/Downloads$ wget http://ftp.uk.debian.org/debian/pool/main/j/jazip/jazip_0.34-15.1+b2_amd64.deb
--2021-04-14 15:09:15--  http://ftp.uk.debian.org/debian/pool/main/j/jazip/jazip_0.34-15.1+b2_amd64.deb
Resolving ftp.uk.debian.org (ftp.uk.debian.org)... 2001:1b40:5600:ff80:f8ee::1, 78.129.164.123
Connecting to ftp.uk.debian.org (ftp.uk.debian.org)|2001:1b40:5600:ff80:f8ee::1|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 81280 (79K) [application/octet-stream]
Saving to: ‘jazip_0.34-15.1+b2_amd64.deb’

jazip_0.34-15.1+b2_amd64.de 100%[===========================================>]  79.38K  --.-KB/s    in 0.08s

2021-04-14 15:09:15 (941 KB/s) - ‘jazip_0.34-15.1+b2_amd64.deb’ saved [81280/81280]

lubuntu@lubuntu:~/Downloads$ sudo dpkg -i jazip_0.34-15.1+b2_amd64.deb
Selecting previously unselected package jazip.
(Reading database ... 240059 files and directories currently installed.)
Preparing to unpack jazip_0.34-15.1+b2_amd64.deb ...
Unpacking jazip (0.34-15.1+b2) ...
Setting up jazip (0.34-15.1+b2) ...
Processing triggers for man-db (2.9.3-2) ...
lubuntu@lubuntu:~/Downloads$ sudo adduser lubuntu floppy
Adding user `lubuntu' to group `floppy' ...
Adding user lubuntu to group floppy
Done.
lubuntu@lubuntu:~/Downloads$ sudo modprobe ppa # Load the parallel port driver for the Zip drive.
lubuntu@lubuntu:~/Downloads$ sudo blkid # Check if the Zip drive has now been detected.
/dev/sda1: LABEL="system" BLOCK_SIZE="512" UUID="BCF27E52F27E10BE" TYPE="ntfs" PARTUUID="6da119a3-01"
/dev/sda2: LABEL="windows" BLOCK_SIZE="512" UUID="527280DF7280C8E5" TYPE="ntfs" PARTUUID="6da119a3-02"
/dev/sdb1: LABEL="usbdata" BLOCK_SIZE="512" UUID="347345C33A9B90D1" TYPE="ntfs" PARTUUID="793c91c2-01"
/dev/sdb3: LABEL_FATBOOT="lub201064" LABEL="lub201064" UUID="7EAA-D59C" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="793c91c2-03"
/dev/sdb4: BLOCK_SIZE="2048" UUID="2020-10-22-14-26-38-00" LABEL="Lubuntu 20.10 amd64" TYPE="iso9660" PTUUID="509643ab-f22d-4d70-8a47-8708c562cbfe" PTTYPE="gpt" PARTUUID="793c91c2-04"
/dev/loop0: TYPE="squashfs"
/dev/sdb5: LABEL="casper-rw" UUID="55459d4d-48f3-4b50-bd9b-3fd71e552bb2" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="793c91c2-05"
/dev/zram0: UUID="073aa55f-241b-4deb-b6a0-907676dfff65" TYPE="swap"
/dev/zram1: UUID="692d4cc6-21fa-48b8-8ef7-948dc13dec53" TYPE="swap"
/dev/sdc4: SEC_TYPE="msdos" LABEL_FATBOOT="ZIP-100" LABEL="ZIP-100" UUID="15F9-2C71" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="726a014e-04"
lubuntu@lubuntu:~/Downloads$ sudo mkdir -p /media/lubuntu/ZIP-100
lubuntu@lubuntu:~/Downloads$ sudo /usr/sbin/jazipconfig
There are currently no entries in /etc/jazip.conf.

Zip devices detected on the system:

  1:  Device /dev/sdc

There are no Jaz devices detected on the system.

Available commands:
 (a)dd an entry listed from detected devices.
 (c)reate an entry from scratch.
 (q)uit without saving.
 (e)xit and save changes.
                           ? a

What mount point? (e.g. /zip) /media/lubuntu/ZIP-100
--------------------------------------------
These are the entries currently selected for /etc/jazip.conf:

  1:   Device /dev/sdc   Mount point /media/lubuntu/ZIP-100

There are no other Zip devices detected on the system.

There are no Jaz devices detected on the system.

Available commands:
 (d)elete an entry from /etc/jazip.conf
 (c)reate an entry from scratch.
 (q)uit without saving.
 (e)xit and save changes.
                           ? e
Creating /etc/jazip.conf
lubuntu@lubuntu:~/Downloads$ cat /etc/jazip.conf
# Configuration file for jaZip
#
# Raw Device         Mount Point                  Read but ignored
  /dev/sdc              /media/lubuntu/ZIP-100                      auto    auto        0 0
lubuntu@lubuntu:~/Downloads$ sudo jazip # Launch jaZip.
ERROR! Couldn't write entry to /etc/mtab.
lubuntu@lubuntu:~/Downloads$ sudo jazip # Launch jaZip.
lubuntu@lubuntu:~/Downloads$ sudo nano /etc/modules # Add ppa so it gets loaded automatically.

 
4. Add a jaZip icon on the Linux Desktop so that you can launch jaZip easily:

4.1 Create the file /home/lubuntu/Desktop/jazip.desktop containing:

[Desktop Entry]
Name=jazip
GenericName=Manage Iomega Jaz and Zip drives
Comment=
Exec=/home/lubuntu/.launch_jazip.sh
Type=Application
Icon=/usr/share/doc/jazip/icons/jazip1.gif
Terminal=false

4.2 Right-click on the icon on the Desktop and tick ‘Trust this executable’.

4.3 Create the file /home/lubuntu/.launch_jazip.sh containing:

#!/bin/bash
lxqt-sudo nohup jazip &

4.4 Make it executable:

lubuntu@lubuntu:~/Downloads$ chmod +x ~/.launch_jazip.sh

jaZip window open on the Lubuntu 20.10 Desktop.

What a pleasure to find that the ppa module, which has been part of the kernel distribution since sometime in the 1.3.x series, is still available and working in today’s Linux kernels, and that jaZip, a utility program for Linux originally released in 1996 and last updated (as far as I can tell) in the year 2001, still works in today’s Linux to manage hardware that has been obsolete for almost as long.

Using jaZip to mount a Zip disk will mount the disk with ownership root:root. Therefore, if I want to copy files to a Zip disk, instead of using jaZip to mount and unmount the disk I click on the device ‘101 MB Volume’ that appears in the Lists pane of the PCManFM-Qt file manager window after a Zip disk is inserted in the drive. I just use jaZip to eject the Zip disk from the drive after unmounting it by clicking on the Unmount icon in the Lists pane of PCManFM-Qt.

Recreating missing WINE menu entries and Desktop Configuration Files in Lubuntu 20.10

I use a few Windows applications I installed via WINE in my user account on my family’s desktop machine running Lubuntu 20.10 (LXQt Desktop Environment). A few days ago I logged in and found that the icons for the Windows applications had disappeared from my Desktop, and the ‘Wine’ entry in the LXQt applications menu had also disappeared. This was rather bizarre and I still have no idea why it happened. However, the directories for each WINEPREFIX were still present so I set about recreating the missing menu entries and Desktop Configuration Files. I reinstalled one of the Windows applications, and its icon reappeared on my Desktop but the ‘Wine’ entry in the LXQt applications menu did not reappear. I had to delve into WINE menu structures to fix everything.

Three key directories are involved in defining the ‘Wine’ menu entries:

~/.config/menus/applications-merged/

~/.local/share/applications/wine/Programs/

~/.local/share/desktop-directories/

The role and contents of these directories are best explained by studying an example of an application in the ‘Wine’ menu. One of the Windows applications I had installed previously via WINE is Visio Professional 5, and I will use it as an example to illustrate how I got everything working again. I had installed the application using a WINEPREFIX of ~/.wine-visio, and the missing icon on my Desktop had been labelled ‘Visio Professional’.

1. I recreated the directory ~/.local/share/applications/wine/Programs/Visio Professional/:

user $ mkdir -p ~/.local/share/applications/wine/Programs/Visio\ Professional

2. I recreated the file ~/.config/menus/applications-merged/wine-Programs-Visio Professional-Visio Professional.menu (chmod 664) containing the following:

<!DOCTYPE Menu PUBLIC "-//freedesktop//DTD Menu 1.0//EN"
"http://www.freedesktop.org/standards/menu-spec/menu-1.0.dtd">
<Menu>
  <Name>Applications</Name>
  <Menu>
    <Name>wine-wine</Name>
    <Directory>wine-wine.directory</Directory>
  <Menu>
    <Name>wine-Programs</Name>
    <Directory>wine-Programs.directory</Directory>
  <Menu>
    <Name>wine-Programs-Visio Professional</Name>
    <Directory>wine-Programs-Visio Professional.directory</Directory>
    <Include>
      <Filename>wine-Programs-Visio Professional-Visio Professional.desktop</Filename>
    </Include>
  </Menu>
  </Menu>
  </Menu>
</Menu>

‘wine-wine‘ corresponds to the ‘Wine’ entry in the top-level LXQt applications menu.

‘wine-Programs‘ corresponds to the second-level menu entry ‘Programs’ (i.e. ‘Wine’ > ‘Programs’).

‘wine-Programs-Visio Professional‘ corresponds to the third-level menu entry ‘Visio Professional’ (i.e. ‘Wine’ > ‘Programs’ > ‘Visio Professional’).

‘wine-Programs-Visio Professional-Visio Professional‘ corresponds to the fourth-level menu entry ‘Visio Professional’ for the application itself (i.e. ‘Wine’ > ‘Programs’ > ‘Visio Professional’ > ‘Visio Professional’).

3. Notice in the above file the syntax for menu directory files corresponding to menu entries. I had to recreate the directory files as follows:

~/.local/share/desktop-directories/wine-wine.directory (chmod 664) containing:

[Desktop Entry]
Type=Directory
Name=Wine
Icon=wine

~/.local/share/desktop-directories/wine-Programs.directory (chmod 664) containing:

[Desktop Entry]
Type=Directory
Name=Programs
Icon=folder

~/.local/share/desktop-directories/wine-Programs-Visio Professional.directory (chmod 664) containing:

[Desktop Entry]
Type=Directory
Name=Visio Professional
Icon=folder

4. I recreated the file ~/.local/share/applications/wine/Programs/Visio Professional/Visio Professional.desktop (chmod 664) containing:

[Desktop Entry]
Name=Visio Professional
Exec=env WINEPREFIX="/home/fitzcarraldo/.wine-visio" wine-stable /home/fitzcarraldo/.wine-visio/drive_c/Program\ Files/Visio/Visio32.EXE
Type=Application
StartupNotify=true
Path=/home/fitzcarraldo/.wine-visio/dosdevices/c:/Program Files/Visio
Comment=Visio Professional
Icon=AAE3_Visio32.0
StartupWMClass=visio32.exe

and I copied the file to ~/Desktop/Visio Professional.desktop (chmod 755). I right-clicked on ~/Desktop/Visio Professional.desktop and ticked ‘Trust this executable’. It is not necessary to do that for .desktop files in ~/.local/share/applications/wine/Programs/ and its sub-directories.

I used the command ‘locate -i visio | grep -i png‘ to find the name of the existing icon file (AAE3_Visio32.0.png) that WINE had created when I originally installed the application. The StartupWMClass variable seems to be the same as the application’s executable file name but all in lower case. I found the Exec and Path entries by examining the existing sub-directories and files in ~/.wine-visio/drive_c/.

The ‘Wine’ menu entry and sub-entries all reappeared correctly after I logged out and back in, and I could again launch the application either by selecting the application from the LXQt application menu or by double-clicking on the application’s icon on my Desktop.

Resulting application menu entry for Windows application Visio Professional 5

The Windows applications are now all usable again, although I wish I knew what caused the problem in the first place.

Anyway the exercise was not a waste of time because I now know how to modify WINE menus. Some Windows application installation programs in WINE result in a menu entry ‘Wine’ > ‘Programs’ > ‘<application>’ > ‘<application>’ whereas others result in a menu entry ‘Wine’ > ‘Programs’ > ‘<application>’, and I now know how to change the menu hierarchy if I want to. For example, I have just now installed the Windows application SumatraPDF to read e-books. The SumatraPDF installation program launched using WINE resulted in a menu entry ‘Wine’ > ‘Programs’ > ‘SumatraPDF’. The resulting file ~/.config/menus/applications-merged/wine-Programs-SumatraPDF.menu contained the following:

<!DOCTYPE Menu PUBLIC "-//freedesktop//DTD Menu 1.0//EN"
"http://www.freedesktop.org/standards/menu-spec/menu-1.0.dtd">
<Menu>
  <Name>Applications</Name>
  <Menu>
    <Name>wine-wine</Name>
    <Directory>wine-wine.directory</Directory>
  <Menu>
    <Name>wine-Programs</Name>
    <Directory>wine-Programs.directory</Directory>
    <Include>
      <Filename>wine-Programs-SumatraPDF.desktop</Filename>
    </Include>
  </Menu>
  </Menu>
</Menu>

Original application menu entry for Windows application SumatraPDF installed via WINE

There was no .directory file for SumatraPDF in ~/.local/share/desktop-directories/ because the menu entry to launch SumatraPDF is under ‘Wine’ > ‘Programs’. If I wanted to change the menu entry to be under ‘Wine’ > ‘Programs’ > ‘SumatraPDF’ I could modify the contents of the file ~/.config/menus/applications-merged/wine-Programs-SumatraPDF.menu, create the file ~/.local/share/desktop-directories/wine-Programs-SumatraPDF.directory, create the directory ~/.local/share/applications/wine/Programs/SumatraPDF/ and move the file ~/.local/share/applications/wine/Programs/SumatraPDF.desktop to ~/.local/share/applications/wine/Programs/SumatraPDF/SumatraPDF.desktop. I decided to do this as an exercise:

user $ mkdir -p ~/.local/share/applications/wine/Programs/SumatraPDF/
$ mv ~/.local/share/applications/wine/Programs/SumatraPDF.desktop ~/.local/share/applications/wine/Programs/SumatraPDF/SumatraPDF.desktop

I edited the file ~/.config/menus/applications-merged/wine-Programs-SumatraPDF.menu so it now contains the following:

<!DOCTYPE Menu PUBLIC "-//freedesktop//DTD Menu 1.0//EN"
"http://www.freedesktop.org/standards/menu-spec/menu-1.0.dtd">
<Menu>
  <Name>Applications</Name>
  <Menu>
    <Name>wine-wine</Name>
    <Directory>wine-wine.directory</Directory>
  <Menu>
    <Name>wine-Programs</Name>
    <Directory>wine-Programs.directory</Directory>
  <Menu>
    <Name>wine-Programs-SumatraPDF</Name>
    <Directory>wine-Programs-SumatraPDF.directory</Directory>
    <Include>
      <Filename>wine-Programs-SumatraPDF-SumatraPDF.desktop</Filename>
    </Include>
  </Menu>
  </Menu>
  </Menu>
</Menu>

I created the file ~/.local/share/desktop-directories/wine-Programs-SumatraPDF.directory containing the following:

[Desktop Entry]
Type=Directory
Name=SumatraPDF
Icon=folder

I logged out and back in, and the application menu entry for SumatraPDF had changed from:

‘Wine’ > ‘Programs’ > ‘SumatraPDF’

where the second-level entry in the ‘Wine’ menu has a folder icon,

to:

‘Wine’ > ‘Programs’ > ‘SumatraPDF’ > ‘SumatraPDF’

where the second-level and third-level entries in the ‘Wine’ menu have folder icons. The other Windows applications in my user account are at the fourth level of the WINE menu, so the Wine menu for SumatraPDF is now consistent with the other Windows applications.

Modified application menu entry for Windows application SumatraPDF installed via WINE

By the way, the Desktop Configuration File ~/Desktop/SumatraPDF.desktop created by WINE contains the following:

[Desktop Entry]
Name=SumatraPDF
Exec=env WINEPREFIX="/home/fitzcarraldo/.wine-sumatra" wine-stable C:\\\\users\\\\fitzcarraldo\\\\Local\\ Settings\\\\Application\\ Data\\\\SumatraPDF\\\\SumatraPDF.exe 
Type=Application
StartupNotify=true
Path=/home/fitzcarraldo/.wine-sumatra/dosdevices/c:/users/fitzcarraldo/Local Settings/Application Data/SumatraPDF
Icon=3EBA_SumatraPDF.0
StartupWMClass=sumatrapdf.exe

and the Desktop Configuration File ~/.local/share/applications/wine/Programs/SumatraPDF.desktop created by WINE contains the following:

[Desktop Entry]
Name=SumatraPDF
Exec=env WINEPREFIX="/home/fitzcarraldo/.wine-sumatra" wine-stable C:\\\\windows\\\\command\\\\start.exe /Unix /home/fitzcarraldo/.wine-sumatra/dosdevices/c:/users/fitzcarraldo/Start\\ Menu/Programs/SumatraPDF.lnk
Type=Application
StartupNotify=true
Path=/home/fitzcarraldo/.wine-sumatra/dosdevices/c:/users/fitzcarraldo/Local Settings/Application Data/SumatraPDF
Icon=3EBA_SumatraPDF.0
StartupWMClass=sumatrapdf.exe

I am not sure why there is a difference in the Exec command in the two files, but that is an investigation for another day.

Addendum (13 March 2021): KDE in Gentoo Linux on my laptops has essentially the same menu structure and files for Windows applications installed via WINE. However, unlike LXQt in Lubuntu 20.10, in addition to the individual .menu file per Windows application KDE has a file (~/.config/menus/applications-kmenuedit.menu) that defines the entire KDE applications menu, not just the Windows applications under ‘Wine’ in the applications menu. To make changes to the menu structure of Windows applications in KDE I therefore have to perform a further step; I have to edit the file ~/.config/menus/applications-kmenuedit.menu, which I have found to be a hassle. The file seems to collect cruft every time a menu entry is created, moved, changed, or deleted. Over time the file can become very large and confusing to read, and it can still contain entries for applications removed years ago. Also, some of the edits I make in the file are not accepted and KDE either reverts the contents or alters the contents in a way I do not want. Therefore I make a copy of the file before editing it, just in case I make a mistake and have to put things back to the way they were.

Enabling other users to login from the xscreensaver lockscreen in Lubuntu 20.10

If Lubuntu 20.10 suspends to RAM, xscreensaver displays a lockscreen with login window when the system resumes. However, LXQt and SDDM currently do not provide a ‘Switch User’ option, so, if you are not the currently logged-in user and you do not know that user’s password, you will be stuck on the xscreensaver lockscreen. If you click on ‘New Login’ in the xscreensaver window, a message similar to the following is displayed and there is no way for a different user to login:

xscreensaver: 19:01:52: could not execute "gdmflexiserver": No such file or directory

To get around this problem so that other users can login, create the file /usr/local/bin/gdmflexiserver containing the following two lines:

#!/bin/bash
who | awk '!/root/{ cmd="/usr/bin/pkill -KILL -u " $1; system(cmd)}'

Make it executable:

$ sudo chmod +x /usr/local/bin/gdmflexiserver

Now, when the xscreensaver login window appears, if you do not know the currently logged-in user’s password you can click on the ‘New Login’ button instead and the SDDM greeter screen will be displayed so that another user can login. Note that clicking on ‘New Login’ will lose all the open windows and any running applications in the current user’s session, but at least a different user will not be prevented from logging-in and using the machine if the original user is not available to login then logout from his/her session. Of course, if the current user is still available, he/she can simply unlock the current session as usual via the xscreensaver lockscreen window.