Among other things, tfm comes with a sidebar, tabs, a dual-pane view, and file previews. The usual file operations like copying, moving, renaming, and deleting are on board as well. What’s interesting: you don’t have to work exclusively with the keyboard. Tfm also supports the mouse, so you can select, move, and rename files by drag and drop, for example.

That way, tfm combines typical features of graphical file managers with the terminal environment. If you spend a lot of time there anyway, you can manage files and directories without opening a separate graphical app.

Installing from the AUR

You can find Tfm in the AUR (Arch User Repository). If you use an AUR helper like yay, you can install the binary version right away. On Arch Linux, this command is all you need:

$ yay -S tfm-tui-bin

After that, start the file manager with:

$ tfm

If you use a different distribution, the project page has instructions for the install script provided there. With it, you install the current version independently of your distribution’s packages.

Nerd Fonts for the icons

For tfm to show folders and files with the intended icons, you need a Nerd Font. These fonts come with additional characters and icons that terminal apps use to display folders, files, and other elements.

For this article, I’m using the Hack Nerd Font. On Arch Linux, the font is available directly in the official repositories and can be installed with pacman:

$ sudo pacman -S ttf-hack-nerd

For tfm to display the icons correctly, the Hack Nerd Font only has to be installed on your system. You don’t need to select the font in your terminal for that. You normally don’t need to refresh the font cache manually for a package from the Arch repositories either.

Beta with a few rough edges

Tfm is still in beta, and you’ll notice it most in how icons are displayed. In my tests, the Nerd Font symbols didn’t show up reliably on every start. Folders and other elements sometimes appear without the icons they’re supposed to have.

Restarting tfm or the terminal usually fixes it. What stands out: the icons come back on the next start even without any changes to the font cache, so the problems can’t be blamed solely on a broken installation of the font.

For graphical image previews, tfm needs a terminal that supports the Kitty Graphics Protocol. On Linux, Ghostty is a good choice, for example, and its Linux interface is built on GTK4. Gnome Terminal can’t offer this feature, because the underlying VTE library doesn’t support the Kitty Graphics Protocol.

The rest of the interface isn’t yet as stable or consistent as what you’re used to from established file managers, either. If you try tfm, start with files that don’t matter, and don’t trust important data to such young software on its own.

The most important keyboard shortcuts

Despite the mouse support, the keyboard plays an important role in tfm. You’ll find the most important commands in the following overview:

All in all, tfm is a likable find for me, especially for anyone who spends all day in the terminal anyway. The sidebar, tabs, dual-pane view, preview and mouse control add a level of comfort you normally don’t get on the command line. If you like, you can even switch on animations – a video on Reddit shows what that looks like.

Keep the quirks of the beta phase in mind, though, above all the icon rendering and the interface, which isn’t quite polished yet. I’ll keep following the development, and right now I’d mainly recommend tfm for trying it out – preferably with non-critical files until the software has matured a bit.

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.

The obvious solution: /etc/fstab plus a dispatcher script for NetworkManager that mounts automatically based on the SSID or on whether the server is reachable. Sounds like an evening project. It isn’t quite. I tripped over three pitfalls that you only notice when the machine shuts down, wakes up, or is supposed to go into standby. Those are the three I’ll walk you through here.

I tested all of this on Arch Linux, but the setup is not Arch-specific. As long as your distro ships systemd and NetworkManager (so Fedora, Ubuntu, Debian or openSUSE, for example), everything here works one to one.

The basic setup

Network shares traditionally get noauto in the fstab, so they are not mounted immediately at boot but only when needed:

//server/home /mnt/server/home cifs credentials=/etc/samba/server.credentials,rw,uid=1000,gid=100,noauto,_netdev 0 0
//server/data /mnt/server/data cifs credentials=/etc/samba/server.credentials,rw,uid=1000,gid=100,noauto,_netdev 0 0

For the mount type itself, the Arch Wiki has good guides depending on the protocol, for example on Samba/CIFS and on davfs2 for WebDAV. Both work on any distribution, as long as cifs-utils or davfs2 are installed.

The actual mounting is then handled by a script in /etc/NetworkManager/dispatcher.d/. NetworkManager calls such scripts on every connection change and passes along the interface and the status (up, down, pre-down and a few more). All the details are in the NetworkManager dispatcher man page. A simple script checks the active Wi-Fi SSID and mounts if it matches:

#!/bin/bash
IFACE="$1"
STATUS="$2"

case "$STATUS" in
    up)
        SSID=$(nmcli -t -f active,ssid dev wifi | awk -F: '$1 == "yes" {print $2; exit}')
        if [[ "$SSID" == "MeinHeimnetz" ]]; then
            mount /mnt/server/home
            mount /mnt/server/data
        fi
        ;;
    down)
        umount /mnt/server/home
        umount /mnt/server/data
        ;;
esac

Done, right? Not quite. As soon as you shut down the system, wake it from standby or put it into standby, it turns out that this approach has its catches.

Why not just use GVfs?

You may now be wondering why I put myself through fstab and dispatcher scripts at all. GNOME offers “Connect to Server” in the file manager, which is a much easier way to mount network shares via SMB or WebDAV. That is exactly where my problem lies.

Such mounts don’t go through the kernel but through GVfs, GNOME’s virtual file system. Programs that use the GIO library (almost all GTK apps, first and foremost the file manager itself) talk to shares directly through their own URIs like smb:// or dav://, and accordingly display thumbnails and metadata correctly. For programs that can’t do that, GVfs additionally exposes the share as a perfectly normal path under /run/user/<uid>/gvfs. This bridge does run through FUSE. GVfs itself is not a classic FUSE file system but its own architecture with a daemon process per protocol, yet for exactly this case it provides a POSIX-compatible path via gvfsd-fuse.

This very bridge is the sticking point for me: not every program copes with it reliably. In my case it shows up in a Markdown editor where I also embed images for articles. The file manager displays the images on the network drive just fine, because it speaks GVfs natively. The Markdown editor, on the other hand, shows only a placeholder for the same image. Access via the FUSE path simply doesn’t work reliably, even though the file is demonstrably there.

A classic kernel mount via CIFS or davfs2, as described in the rest of this article, shows up as a perfectly normal, stable POSIX path in the file system, with no special treatment and the same for every program. So the extra effort with fstab and dispatcher scripts pays off precisely when you want to use shares reliably not just in the file manager but in all kinds of apps.

Problem 1: The computer doesn’t shut down cleanly anymore

If the fstab lacks the option _netdev, systemd doesn’t know that this is a network share. On shutdown, systemd may then try to unmount after the network is already gone. The umount blocks until the job timeout kicks in, and your system hangs on shutdown.

_netdev fixes that, because systemd then knows the right order: unmount first, then cut the network. It is also important that a dispatcher script reacts not just to down but to pre-down. That status fires before the connection actually drops, while down comes afterward and is too late for a clean unmount. For this to work, you additionally need a symlink in the subfolder pre-down.d/.

Problem 2: The file manager freezes after waking up

A mount call for CIFS or WebDAV runs in the kernel and can block for quite a while if the server is unreachable, especially right after waking up, when DNS or routing aren’t fully back yet. By default, NetworkManager waits synchronously until such a dispatcher script has finished before it carries on. If the mount call hangs, suddenly your file manager or the network indicator hangs too, because they depend on the connection state.

The fix: just run the mount attempts in the background, so the dispatcher script itself returns immediately, no matter how long the actual mount takes.

run_async() {
    ( "$@" ) &>/dev/null &
    disown
}

Problem 3: Suspend suddenly stops working

And this is where it gets interesting. With the fix from problem 2 you stumble into a new and much nastier problem, which in my case looked like this: the screen turns off, but the keyboard backlight and LEDs stay on, and you have to force a hard power-off. What happened?

The mount syscall for CIFS or davfs blocks with an unreachable server in the so-called D state (uninterruptible sleep), a state that no signal can interrupt, not even SIGKILL. Before the kernel actually goes to sleep, it tries to freeze all processes. A process in D state can’t be frozen, so the whole suspend hangs until the network operation in the kernel gives up on its own, which can easily take a few minutes.

Because the mount attempts from problem 2 now keep running in the background for longer, the chance also goes up that such a blocking connection attempt is active at exactly the moment you want to suspend.

The reliable way out: before every mount, first check with a real userspace connection test whether the server is reachable at all. That kind of test can actually be aborted with a timeout, for example via Bash’s built-in /dev/tcp:

tcp_reachable() {
    local HOST="$1"
    local PORT="$2"
    local TIMEOUT_SECONDS="${3:-2}"
    timeout "${TIMEOUT_SECONDS}s" bash -c "echo >/dev/tcp/${HOST}/${PORT}" &>/dev/null
}

Only if the test succeeds does the actual mount follow. That way you almost never end up in the risky, blocking kernel connect, because by then you already know the server is there.

The combination that works for me

In the end, a robust setup needs four ingredients:

• _netdev in the fstab, so systemd classifies network shares correctly on shutdown.
• pre-down handling plus a symlink in pre-down.d/, so the unmount is guaranteed to happen before the connection is torn down, with a timeout and lazy unmount as a backup in case the normal umount acts up.
• Asynchronous mounts on up, so NetworkManager and everything that depends on it doesn’t block.
• A reachability test before every mount, so the actual, potentially blocking kernel connect never happens in the first place.

On top of that, a small health check via a systemd timer that looks a few minutes after boot and regularly afterward to see whether the shares are really there, and nudges things along if needed. Handy in case the triggering network event comes too early or too late.

All files at a glance

So you can rebuild all of this right away, here is the complete set of files. I replaced the example names from my own setup (a Samba server called bender, WebDAV via tuxedo) with generic placeholders. You’ll of course have to adapt them to your own environment.

/etc/fstab: the two shares, one Samba, one WebDAV:

//server/home /mnt/server/home cifs credentials=/etc/samba/server.credentials,rw,uid=1000,gid=100,noauto,_netdev,x-systemd.mount-timeout=15s,soft 0 0
//server/data /mnt/server/data cifs credentials=/etc/samba/server.credentials,rw,uid=1000,gid=100,noauto,_netdev,x-systemd.mount-timeout=15s,soft 0 0
https://cloud.example.com/remote.php/dav/files/user /mnt/webdav davfs noauto,_netdev,uid=1000,gid=100,x-systemd.automount,x-systemd.idle-timeout=300,x-systemd.mount-timeout=15s 0 0

The fstab only references the credentials; they are stored in separate files, if only so the password doesn’t sit in plain text in a file that everyone can read.

/etc/samba/server.credentials: credentials for the Samba share:

username=maxmuster
password=GeheimesPasswort123

/etc/davfs2/secrets: credentials for the WebDAV share. Here the mount point is referenced instead of an option in the fstab:

/mnt/webdav maxmuster GeheimesPasswort123

Both files belong to root and must not be readable by anyone else:

$ sudo chmod 600 /etc/samba/server.credentials /etc/davfs2/secrets
$ sudo chown root:root /etc/samba/server.credentials /etc/davfs2/secrets

/etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh: the shared library that all the other scripts source:

#!/bin/bash
log() {
    [[ "$DEBUG" == "1" ]] && logger -t "$LOG_TAG" -- "$1"
}

run_async() {
    ( "$@" ) &>/dev/null &
    disown
}

tcp_reachable() {
    local HOST="$1"
    local PORT="$2"
    local TIMEOUT_SECONDS="${3:-2}"
    timeout "${TIMEOUT_SECONDS}s" bash -c "echo >/dev/tcp/${HOST}/${PORT}" &>/dev/null
}

mount_with_retry() {
    local MOUNT="$1"
    local MAX_ATTEMPTS="${2:-3}"
    local SLEEP_SECONDS="${3:-2}"
    local MOUNT_TIMEOUT="${4:-10}"

    if mountpoint -q "$MOUNT"; then
        log "$MOUNT ist bereits eingehängt"
        return 0
    fi

    log "Hänge $MOUNT ein"

    local OUT ATTEMPT
    for ((ATTEMPT = 1; ATTEMPT <= MAX_ATTEMPTS; ATTEMPT++)); do
        if OUT=$(timeout "${MOUNT_TIMEOUT}s" mount "$MOUNT" 2>&1); then
            log "$MOUNT erfolgreich eingehängt"
            return 0
        fi
        log "Versuch $ATTEMPT/$MAX_ATTEMPTS für $MOUNT fehlgeschlagen (evtl. Timeout nach ${MOUNT_TIMEOUT}s): $OUT"
        &#91;&#91; "$ATTEMPT" -lt "$MAX_ATTEMPTS" ]] && sleep "$SLEEP_SECONDS"
    done

    log "Alle Versuche für $MOUNT fehlgeschlagen"
    return 1
}

umount_with_fallback() {
    local MOUNT="$1"
    local TIMEOUT_SECONDS="${2:-5}"

    if ! mountpoint -q "$MOUNT"; then
        log "$MOUNT ist nicht eingehängt"
        return 0
    fi

    log "Hänge $MOUNT aus"

    if timeout "${TIMEOUT_SECONDS}s" umount "$MOUNT"; then
        log "$MOUNT erfolgreich ausgehängt"
        return 0
    fi

    log "Normaler Unmount von $MOUNT fehlgeschlagen, versuche Lazy Unmount"
    if umount -l "$MOUNT"; then
        log "$MOUNT per Lazy Unmount ausgehängt"
        return 0
    fi

    log "$MOUNT konnte nicht ausgehängt werden"
    return 1
}

/etc/NetworkManager/dispatcher.d/90-server-mount: Samba share, bound to a specific Wi-Fi SSID or to the wired network:

#!/bin/bash

DEBUG=1
LOG_TAG="server-mount"

LIB="/etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh"
if [[ -r "$LIB" ]]; then
    source "$LIB"
else
    logger -t "$LOG_TAG" -- "Bibliothek $LIB nicht gefunden, breche ab"
    exit 1
fi

IFACE="$1"
STATUS="$2"

MOUNTS=(
    "/mnt/server/home"
    "/mnt/server/data"
)

mount_server() {
    if ! tcp_reachable server 445 2; then
        log "server auf Port 445 nicht erreichbar, überspringe Mount-Versuch"
        return 1
    fi

    for MOUNT in "${MOUNTS[@]}"; do
        mount_with_retry "$MOUNT" 3 2 10
    done
}

umount_server() {
    for MOUNT in "${MOUNTS[@]}"; do
        umount_with_fallback "$MOUNT" 5
    done
}

log "Dispatcher gestartet: Interface=$IFACE, Status=$STATUS"

case "$STATUS" in
    up)
        if [[ "$IFACE" == wl* ]]; then
            SSID=$(nmcli -t -f active,ssid dev wifi |
                awk -F: '$1 == "yes" {print $2; exit}')

            log "Aktive WLAN-SSID: $SSID"

            if [[ "$SSID" == "MeinHeimnetz" ]]; then
                run_async mount_server
            fi

        elif [[ "$IFACE" == enp* || "$IFACE" == eth* ]]; then
            run_async mount_server
        fi
        ;;

    pre-down|vpn-pre-down)
        log "Netzwerkverbindung wird beendet – Mounts aushängen"
        umount_server
        ;;
esac

log "Dispatcher beendet"
exit 0

/etc/NetworkManager/dispatcher.d/90-webdav-mount: WebDAV share, which simply requires a reachable cloud server:

#!/bin/bash

DEBUG=1
LOG_TAG="webdav-mount"

LIB="/etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh"
if [[ -r "$LIB" ]]; then
    source "$LIB"
else
    logger -t "$LOG_TAG" -- "Bibliothek $LIB nicht gefunden, breche ab"
    exit 1
fi

IFACE="$1"
STATUS="$2"

MOUNTPOINT="/mnt/webdav"
HOST="cloud.example.com"

mount_webdav() {
    if ! tcp_reachable "$HOST" 443 3; then
        log "$HOST auf Port 443 nicht erreichbar, überspringe Mount-Versuch"
        return 1
    fi

    mount_with_retry "$MOUNTPOINT" 3 2 10
}

log "Dispatcher gestartet: Interface=$IFACE, Status=$STATUS"

case "$STATUS" in
    up)
        run_async mount_webdav
        ;;

    pre-down|vpn-pre-down)
        log "Netzwerkverbindung wird beendet – Mount aushängen"
        umount_with_fallback "$MOUNTPOINT" 5
        ;;
esac

log "Dispatcher beendet"
exit 0

For both scripts you also need the matching symlinks, so that pre-down is guaranteed to fire before the connection is torn down:

$ sudo ln -s /etc/NetworkManager/dispatcher.d/90-server-mount 
             /etc/NetworkManager/dispatcher.d/pre-down.d/90-server-mount
$ sudo ln -s /etc/NetworkManager/dispatcher.d/90-webdav-mount 
             /etc/NetworkManager/dispatcher.d/pre-down.d/90-webdav-mount

/usr/local/bin/mount-healthcheck.sh: the safety net that checks regularly:

#!/bin/bash
DEBUG=1
LOG_TAG="mount-healthcheck"

LIB="/etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh"
if [[ -r "$LIB" ]]; then
    source "$LIB"
else
    logger -t "$LOG_TAG" -- "Bibliothek $LIB nicht gefunden, breche ab"
    exit 1
fi

log "Healthcheck gestartet"

SSID=$(nmcli -t -f active,ssid dev wifi 2>/dev/null |
    awk -F: '$1 == "yes" {print $2; exit}')

if [[ "$SSID" == "MeinHeimnetz" ]] || ping -c 1 -W 1 server >/dev/null 2>&1; then
    mount_with_retry "/mnt/server/home" 2 3
    mount_with_retry "/mnt/server/data" 2 3
else
    log "server im aktuellen Netz nicht erreichbar, überspringe"
fi

mount_with_retry "/mnt/webdav" 2 3

log "Healthcheck beendet"
exit 0

/etc/systemd/system/mount-healthcheck.service and mount-healthcheck.timer: systemd units that trigger the health check script 60 seconds after boot and every 10 minutes after that:

[Unit]
Description=Prueft und stellt Netzwerk-Mounts sicher
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
TimeoutStartSec=120
ExecStart=/usr/local/bin/mount-healthcheck.sh

[Unit]
Description=Fuehrt den Mount-Healthcheck 60s nach Boot und danach alle 10 Minuten aus

[Timer]
OnBootSec=60s
OnUnitActiveSec=10min
AccuracySec=30s

[Install]
WantedBy=timers.target

Don’t forget to enable it:

$ sudo systemctl daemon-reload
$ sudo systemctl enable --now mount-healthcheck.timer

/usr/lib/systemd/system-sleep/90-cancel-network-mounts: an optional safety net before suspend:

#!/bin/bash
case "$1/$2" in
    pre/*)
        logger -t sleep-mount-guard "Breche evtl. laufende Netzwerk-Mount-Versuche vor Suspend ab"
        pkill -9 -f 'mount.cifs' 2>/dev/null
        pkill -9 -f 'mount.davfs' 2>/dev/null
        ;;
esac

exit 0

All scripts have to be executable:

$ sudo chmod +x /etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh 
              /etc/NetworkManager/dispatcher.d/90-server-mount 
              /etc/NetworkManager/dispatcher.d/90-webdav-mount 
              /usr/local/bin/mount-healthcheck.sh 
              /usr/lib/systemd/system-sleep/90-cancel-network-mounts

Long story short

Automatically mounting network shares via NetworkManager works well, but it is not a five-minute job, as the docs might make you think. If you just put the mount command into an up script, sooner or later one of the three problems will catch up with you, usually exactly when you’re on the road and have no log at hand.

With _netdev, correct pre-down timing, asynchronous execution and a real reachability test before every mount, you’re on the safe side. And the pattern carries over one to one to other network-dependent automations, such as VPN connections or backup jobs that should only run on the right network.

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.

The culprit is an update to the official Electron-based Linux client that messed up the GTK-style window decoration. Spotify itself works just as before, but visually it looks anything but nice.

Solutions for Spotify

There are two easy ways to fix the problem. The most convenient one is to install Spotify as a Flatpak. The Flatpak version doesn’t show the blue frame, and you don’t have to worry about anything. No configuration changes are needed.

If you installed Spotify via the Spotify Launcher (the spotify-launcher package from Arch’s extra repository) or directly from the AUR (the spotify entry), you need to set the launch flag --ozone-platform=x11 instead. That makes the GTK decoration show up correctly. Depending on how you installed it, add the flag like this:

For AUR Spotify in the file ~/.config/spotify-flags.conf:

--ozone-platform=x11

For Spotify Launcher in ~/.config/spotify-launcher.conf:

[spotify]
extra_arguments = ["--ozone-platform=x11"]

You may have to create these files first. After restarting Spotify, the blue frame should be gone and everything should look normal again.

Correction from Fabian on Mastodon: That’s not quite right. This is solely down to Spotify running natively on Wayland, where under GNOME it needs a client-side decoration (CSD), which it provides through that blue one. Forcing it back to X11 might cause real problems, like blurry fonts, bad (or no) scaling and so on. Also, Spotify isn’t Electron, it’s the Chromium Embedded Framework (CEF).

Sure, it’s a crutch, but one that helps right now. And you can undo the change quickly, too. The other options would be to run GNOME under X11 or to make friends with the blue frames. To me, neither is exactly ideal. So for now this is a workaround, and of course you shouldn’t forget about it in case Spotify starts acting up again at some point.

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.

I used to use Shutter for this. Unfortunately, it has since lost its Wayland support and hasn’t seen any development for quite some time. As my current alternative, I use KSnip to add notes and markings, even if that means pulling a pile of Qt libraries onto my system. What I’m still missing, though, is a magnifier effect that lets me enlarge small details in my screenshots and call them out.

You can do this effect quickly and easily in GIMP, though, even if there is no dedicated filter for it. In this guide, I’ll show you how to create a magnifier effect on your screenshots in just a few minutes.

Step-by-step guide to the magnifier effect in GIMP

Open the screenshot

First, open your screenshot in GIMP. If you haven’t taken a screenshot yet, you can do that right in GIMP: in the menu, choose File » Create » Screenshot. There you can either capture the screenshot directly in the program or import an earlier one.

Select the area

Now pick the Rectangle Select tool or the Ellipse Select tool from the toolbox on the left. Drag the selection around the area you want to enlarge, that is, the area you later want to highlight with the magnifier effect. To create a circular selection with the ellipse tool, hold down the Shift key while dragging with the mouse.

Once the selection is made, press Ctrl+C on the keyboard to copy the area. Then press Ctrl+V to paste it as a new floating selection. This new selection shows up in the upper right area of GIMP as Floating Selection. Right-click it and choose To New Layer to turn the floating selection into a regular layer named Transformation.

Enlarge the selection

Now comes the actual magnifier effect: choose the Scale tool from the toolbox on the left and click the new layer you just created. Enlarge it until it gives you the “magnifying glass” look you want. Make sure to lock the aspect ratio so the proportions of the selection stay intact.

Fit the layer to the image size

Right-click the new layer in the right panel and choose Layer to Image Size. This fits the layer to the overall image size without changing any of the other elements in the screenshot.

Add a selection around the effect

Right-click the layer in the right panel again, and this time choose Alpha to Selection. This makes the non-transparent area of the layer selectable.

Add an outline

Now go to Edit » Stroke Selection … and adjust the properties of the outline. Here you can pick the color and the thickness of the line. The default color is taken from GIMP’s foreground color. Unfortunately, there is no preview for this function. Click OK to apply the outline.

Adjust the background

Last but not least, you can apply a filter to the background to strengthen the effect further. A blur or a shadow on the new layer helps the magnifier effect come into its own. To do that, pick Filters and try out different options, such as Blur or Drop Shadow.

With these simple steps, you’ve created an effective magnifier effect in GIMP. It takes a bit of practice and fine-tuning, but after a few tries you’ll get a good feel for the tools and can work them efficiently into your screenshot editing. Especially handy: you can use the method on any part of an image, to highlight not just text but any other detail in your screenshots.

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.

It gets especially annoying when the monitor GDM uses for the login isn’t even turned on. Then the screen stays black and I’m fumbling around in the dark until I open the laptop lid or figure out which monitor is the right one. Apparently GDM uses its own configuration, which has nothing to do with the display settings of the GNOME session. In the Arch Linux wiki I came across a solution that fixes this behavior reliably, and it works on other distributions as well.

Why GDM uses the wrong monitor

The problem typically shows up on systems with multiple screens, especially when proprietary graphics drivers such as Nvidia’s are in use. GNOME stores the screen layout per user in a file called monitors.xml in the directory ~/.config. GDM, on the other hand, uses its own configuration in the context of the gdm user. Since this file is not automatically synced with the one of your main user when the system is set up, the login screen can end up on the wrong screen, and stay there.

Manual solution: copy your display settings

The easiest way to teach GDM the right monitor configuration is to copy the monitors.xml file from your home directory to the GDM configuration directory.

1. First, set up the screen configuration you want in GNOME. Open the display settings via:

$ <strong>gnome-control-center display</strong>

Pick your preferred main screen and arrange the monitors as you like. The changes are saved automatically in your home directory under ~/.config/monitors.xml.

2. Copy the file to the GDM home directory:

$ <strong>sudo install -o root -m 644 ~/.config/monitors.xml ~gdm/.config/</strong>

The system correctly interprets the home directory of the GDM user ~gdm here.

3. Restart GDM so the new configuration is picked up. Careful: this ends your current GNOME session without warning:

$ <strong>sudo systemctl restart gdm</strong>

After the restart, the login screen should show up on the monitor you want.

Automated solution: with a systemd service

If you often work with different monitor setups or simply prefer a permanent solution, you can automate copying the file at boot.

1. Create the directory for the systemd override:

$ <strong>sudo mkdir -p /etc/systemd/system/gdm.service.d</strong>

2. Create a new configuration file override.conf with the following content:

[Service]
ExecStartPre=/bin/sh -c 'install -o root -m 644 /home/EUER_NUTZER/.config/monitors.xml ~gdm/.config/monitors.xml || true'

Replace EUER_NUTZER with your actual user name.

3. Reload the systemd configuration:

$ <strong>sudo systemctl daemon-reexec</strong>

The next time GDM starts, the file is picked up automatically.

Even easier: with the graphical GDM Settings

Last but not least, there is a graphical alternative. With the app GDM Settings you can configure many details of the login manager, including applying your display settings. Simply with a mouse click and without the command line.

The app is not an official GNOME tool and usually isn’t in the repositories either. You can install it without trouble via Flathub, though. Pay attention to the warning on first launch: use at your own risk. Many options change system files, which can cause problems in individual cases, but as a rule everything works as intended.

To apply the screen configuration of the currently logged-in user, open Display in the sidebar and click Apply Current Display Settings [CHECK: exact English label]. There is no automatic transfer for changing setups here, though. If you use your laptop regularly between the office and a home office, each with a different monitor configuration, the systemd variant described above is possibly the better choice.

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.

The cause is the audio detection of the GNOME Settings Daemon, which in some cases can’t automatically tell a headset from simple headphones. So far, there is no built-in option to turn the dialog off for good. An extension fixes that.

A simple fix: Auto Select Headset

The GNOME Shell extension Auto Select Headset suppresses the “Select Audio Device” dialog on systems without automatic jack detection. Instead, it tells the system right away that a headset has been plugged in. The extension is for anyone who prefers the audio device to be picked automatically and doesn’t want to be asked every time. The source code is available on GitHub.

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.

Checking USB sticks for errors

First, you need to find out the device ID of the USB stick or memory card. So plug the device into your computer or insert the SD card into the card reader and type lsblk in the terminal. The command lists all storage devices connected to the computer. As a rule, you can identify the device ID by the size of the device. In my example, the system attaches my 8 GB USB stick as sdc (that is, /dev/sdc in full). If you’re unsure, unplug the device you want to check and run lsblk again. If sdc is missing from the list, you have the right ID. Alternatively, graphical tools such as GNOME Disks also show the ID.

$ lsblk
[...]
sdc           8:32   1   7.5G  0 disk
├─sdc1        8:33   1   2.9G  0 part /run/media/toff/Ubuntu 21.10 amd64
├─sdc2        8:34   1   4.1M  0 part
└─sdc3        8:35   1   300K  0 part
[...]

For the actual error check, the badblocks command from the e2fsprogs package comes into play, which is part of the standard installation of the usual distributions. Badblocks may refuse to start the check at first because the drive is supposedly in use by the system. This usually happens because the operating system mounts the device automatically as soon as you plug in the USB stick. On my system, clicking the eject icon in the file manager isn’t enough; I have to unmount the device ID of the drive and its partitions explicitly with umount.

Caution: I have to issue a warning at this point: when checking for errors, Badblocks overwrites all data and partitions on the specified device. So make absolutely sure you pass the right device ID to the command, and back up important data from the USB stick or SD memory card beforehand. If the worst happens, you won’t be able to recover the data after the check.

$ sudo badblocks -wsv /dev/sdc
/dev/sdc is apparently in use by the system; it's not safe to run badblocks!
$ sudo umount /dev/sdc*
umount: /dev/sdc: not mounted.
umount: /dev/sdc2: not mounted.
umount: /dev/sdc3: not mounted.

When calling Badblocks, you pass the parameters -wsv and the device ID. The parameters tell the program to run a destructive write test (-w), show the progress (-s) and output more information in general (-v). The thorough test writes every block of the device four times in a row with different patterns (0xaa, 0x55, 0xff and 0x00). Depending on speed and capacity, you need to allow quite some time for this. Checking the USB 2.0 stick with 8 GB of capacity from my example took more than an hour.

$ sudo badblocks -wsv /dev/sdc
Testing with pattern 0xaa:   0.00% done, 0:00 elapsed. (0/0/0 errors) done
Reading and comparing: done
Testing with pattern 0x55:   0.00% done, 23:47 elapsed. (0/0/0 errors) done
Reading and comparing: done
Testing with pattern 0xff:   0.00% done, 47:33 elapsed. (0/0/0 errors) done
Reading and comparing: done
Testing with pattern 0x00:   0.00% done, 1:11:26 elapsed. (0/0/0 errors) done
Reading and comparing: done

Besides the destructive method, Badblocks supports a non-destructive read-write mode. You enable it with the -n parameter instead of -w. In this variant, Badblocks first backs up the data of the block being checked to RAM, then overwrites the block with random data and checks whether the data was written correctly. Finally, Badblocks writes the backup back to the device. At first glance, this routine seems faster because there is only one pass, but in practice backing up and restoring the existing data takes considerably more time. In my example, it took more than 2.5 hours instead of just over one hour.

$ sudo badblocks -nsv /dev/sdc
Checking for bad blocks in non-destructive read-write mode
From block 0 to 7812607
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern:  94.36% done, 2:35:18 elapsed. (0/0/0 errors)

Detecting fake USB sticks

The tool F3, short for Fight Flash Fraud, goes one step further. The open-source program thoroughly checks whether a storage device really has the capacity it claims to have. Unfortunately, this is still a relevant topic, especially if you buy super cheap deals online. To expose fake USB sticks or SD memory cards, install the program from your distribution’s repositories. Debian, Ubuntu, Fedora and others carry the command-line tool in their official repositories; the package is usually called f3. Arch Linux only has the program in the AUR, so you need an AUR helper to install it.

### Installation on Arch Linux or Manjaro:
$ yay -S f3
### Installation on Debian, Ubuntu or Raspberry Pi OS:
$ sudo apt install f3

The commands for checking USB storage are f3write, f3read and f3probe. You have to use the first two in combination, passing each the mount point of the device as an option. f3write keeps writing one-gigabyte files to the mounted device until it runs out of space. Then you use f3read to check whether the written data can really be read back. If the device is a fake USB stick or a manipulated SD memory card, f3read would report corrupted sectors. This check leaves all data on the device intact; you just have to delete the h2w files at the end, otherwise there’s no space left on the stick.

$ f3write /run/media/toff/291E-6F9C
[...]
Free space: 3.72 GB
Creating file 1.h2w ... OK!
Creating file 2.h2w ... OK!
Creating file 3.h2w ... OK!
Creating file 4.h2w ... OK!
Free space: 0.00 Byte
Average writing speed: 3.91 MB/s
$ f3read /run/media/toff/291E-6F9C
[...]
                  SECTORS      ok/corrupted/changed/overwritten
Validating file 1.h2w ... 2097152/        0/      0/      0
Validating file 2.h2w ... 2097152/        0/      0/      0
Validating file 3.h2w ... 2097152/        0/      0/      0
Validating file 4.h2w ... 1518736/        0/      0/      0

  Data OK: 3.72 GB (7810192 sectors)
Data LOST: 0.00 Byte (0 sectors)
	       Corrupted: 0.00 Byte (0 sectors)
	Slightly changed: 0.00 Byte (0 sectors)
	     Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 14.73 MB/s
$ ls -al /run/media/toff/291E-6F9C
total 3907596
drwxr-xr-x  3 toff toff       4096 Jan  1  1970 .
drwxr-x---+ 4 root root         80 Dec  7 16:27 ..
-rw-r--r--  1 toff toff 1073741824 Dec  7 18:35 1.h2w
-rw-r--r--  1 toff toff 1073741824 Dec  7 18:40 2.h2w
-rw-r--r--  1 toff toff 1073741824 Dec  7 18:44 3.h2w
-rw-r--r--  1 toff toff  777592832 Dec  7 18:47 4.h2w
[...]

f3probe --destructive works a little faster. The --destructive option is optional, but it speeds things up considerably. In this test, F3 only writes the sectors it absolutely needs and doesn’t bother with backing up data. Since the probe accesses the hardware directly, you pass the device ID (here /dev/sdg) instead of the mount point. This way, the test with my 4 GB USB 2.0 stick takes only a little more than seven minutes. Keep in mind again, though, that this routine overwrites all data blocks on the device.

$ f3probe --destructive --time-ops /dev/sdg
[...]
Good news: The device `/dev/sdg' is the real thing

Device geometry:
	         *Usable* size: 3.73 GB (7831552 blocks)
	        Announced size: 3.73 GB (7831552 blocks)
	                Module: 4.00 GB (2^32 Bytes)
	Approximate cache size: 0.00 Byte (0 blocks), need-reset=no
	   Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 7'17"
 Operation: total time / count = avg time
      Read: 2.73s / 4812 = 568us
     Write: 7'13" / 3637313 = 119us
     Reset: 1us / 1 = 1us

Both Badblocks and F3 help you analyze errors on storage devices. You always need to bring a bit of time for the check, though. A thorough analysis of an 8 GB USB stick can easily take two hours, especially if the data is to be preserved during the check and the stick only supports the slow USB 2.0 protocol. Afterward, however, you can assume that the USB stick or SD memory card really works and has the capacity printed on the label.

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.

When establishing a connection via SSH, the SSH client usually stores the public SSH key of the remote system together with its hostname and IP address in the file ~/.ssh/known_hosts in the current user’s home directory on the client machine. Among other things, this is done to prevent man-in-the-middle attacks, in which an attacker pretends to be the target machine in order to phish your login credentials. However, this security measure also kicks in when there is no threat at all: for example, when you set up a Pi from scratch and try to log in via SSH again. In such a case, SSH reports WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED in big letters.

SSH after reinstalling the system

$ grep 192.168.111.100 ~/.ssh/known_hosts
raspberrypi,192.168.111.100 ecdsa-sha2-nistp256 AAAAE2...ABBBBqf

$ ssh pi@192.168.111.100
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:6rR+0/i3KnPLds3EuGkfWiudIgu8VMpe1xq+X3I3yNM.
Please contact your system administrator.
Add correct host key in /home/toff/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/toff/.ssh/known_hosts:10
ECDSA host key for 192.168.111.100 has changed and you have requested strict checking.
Host key verification failed.

You could now open the file ~/.ssh/known_hosts in a text editor and delete the offending line 10 from the list by hand, but there is a better way: with ssh-keygen -R IP-address, you remove the key from the file with a single command, so the next time you connect, you start from scratch – and have to confirm the key just like the very first time you connected to this machine. This also works if you use the hostname instead of the IP address to connect. To be on the safe side, the command copies the old state to ~/.ssh/known_hosts.old in the same directory.

$ ssh-keygen -R 192.168.111.100
# Host 192.168.111.100 found: line 10
/home/toff/.ssh/known_hosts updated.
Original contents retained as /home/toff/.ssh/known_hosts.old

$ ssh pi@192.168.111.100
The authenticity of host 'raspberrypi (192.168.111.100)' can't be established.
ECDSA key fingerprint is SHA256:6rR+0/i3KnPLds3EuGkfWiudIgu8VMpe1xq+X3I3yNM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.111.100' (ECDSA) to the list of known hosts.
pi@192.168.111.100's password:

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Apr 22 08:40:10 2016 from 192.168.178.57

Forcibly terminating an SSH connection

If you are logged in to a remote machine via SSH and shut it down with shutdown, halt or reboot, the system doesn’t kill the SSH connection abruptly. It stops the SSH server cleanly during shutdown, so you end up back in the terminal of the client machine and can keep working in the same terminal window. Now, I – and surely other Pi tinkerers too – like to unplug the Raspberry Pi and plug it back in to restart it quickly and painlessly. This is certainly not ideal for the integrity of the data on the memory card, but if I’m going to set up the system on it from scratch anyway, I don’t much care.

The downside is that SSH usually hangs in the terminal when you do this – after all, you just pulled the chair out from under it. You could now kill the SSH process or close the terminal window and open it again, but there is a clean solution for this situation, too: SSH knows a number of escape sequences that let you manage the current SSH session. You get an overview of the available commands if you type ~? on a new line in the terminal. To be on the safe side, simply press Enter once beforehand.

pi@raspberrypi:~ # ~?
Supported escape sequences:
 ~.   - terminate connection (and any multiplexed sessions)
 ~B   - send a BREAK to the remote system
 ~C   - open a command line
 ~R   - request rekey
 ~V/v - decrease/increase verbosity (LogLevel)
 ~^Z  - suspend ssh
 ~#   - list forwarded connections
 ~&   - background ssh (when waiting for connections to terminate)
 ~?   - this message
 ~~   - send the escape character by typing it twice
(Note that escapes are only recognized immediately after newline.)

The first sequence shown in the help is exactly the function we’re looking for: if you type ~. as text during an SSH session, you terminate the current SSH connection, no matter what. This doesn’t only work with a session that is still active and working (which you could close with exit at any time anyway), but also when, for example, you cut the power to the Pi and nothing happens in the terminal anymore. Here, too, it can help to press Enter once more before the actual command. Otherwise the escape sequence may come to nothing.

Pausing and resuming an SSH connection

The escape sequences can do other handy things, too. For example, you can suspend an SSH connection and resume it later without having to use a terminal multiplexer such as screen or tmux. If a process takes longer than expected, you can park the connection this way while the process on the remote machine keeps running. Unlike with the two terminal multiplexers mentioned, you don’t have to think ahead that the task might take longer and start them as a precaution. The corresponding sequence is the somewhat cryptic ~^Z, where the caret doesn’t stand for a character but for the Ctrl key. So you type ~ and then press Ctrl+Z. You then land back in the terminal of the machine on which you originally ran ssh. From there, you can pick up the connection again by typing fg and pressing Enter.

If you work on a “truly” remote system over the internet, the connection may well drop. On the one hand, this is because the server terminates the connection after a period of inactivity; on the other hand, your own network infrastructure (read: the router) may interfere. However, you can prevent the timeout with a keep-alive function. Depending on the situation, you can either configure the SSH server accordingly (which of course requires root privileges) or call SSH with the appropriate parameters right away. In that case, you don’t need any special privileges on either system.

Keep-alive on the server side

### Default keep-alive settings:
$ grep Alive /etc/ssh/sshd_config
#TCPKeepAlive yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
### Edit the SSH server configuration:
$ sudo nano /etc/ssh/sshd_config

### In the end, the relevant lines should look like this:
$ grep Alive /etc/ssh/sshd_config
TCPKeepAlive yes
ClientAliveInterval 60
ClientAliveCountMax 3

### Restart the SSH server once:
$ sudo systemctl restart sshd

Keep-alive on the client side

### Keep the SSH connection alive from the client side
$ ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=1 pi@raspberrypi

In the first case, the setting applies to all users who want to log in to the system via SSH. As a rule, you should therefore only make this change if all users actually need it. Most of the time, though, you only need keep-alive in exceptional cases, so it makes sense to set the option only when needed when calling ssh. For me, this is the case with a web service I can log in to via SSH, for example. If I start long-running backups there, my router terminates the connection before the backup process can report success. With the keep-alive settings mentioned above, however, that’s no longer a problem.

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.