So I’m glad there’s Ghostty, a modern terminal with tiling built on GTK 4 and libadwaita. On my machine, it has replaced Tilix, which I introduced back in 2016 under its old name Terminix (in German). I covered Ghostty in depth in the German magazine LinuxUser, issue 06/2026. Now version 1.4 is out, and it brings quite a few changes that matter to Linux users in particular.

What is Ghostty?

If you haven’t come across Ghostty yet: the terminal comes from Mitchell Hashimoto, whom many of you will know as the founder of HashiCorp (Vagrant, Terraform). Ghostty aims to be fast and feature-rich while still feeling like a regular desktop app. On Linux, it uses GTK 4 for that and fits in nicely with GNOME. Ghostty is free software under the MIT license.

Tabs, splits and an overview of all open tabs come built in. You open new splits with Ctrl+Shift+O to the right and with Ctrl+Shift+E below. What you won’t find is a menu bar with settings dialogs. You configure Ghostty in the text file ~/.config/ghostty/config. On top of that, programs running in Ghostty can show images right in the terminal, for example as a preview in a file manager.

Less memory for weaker machines

Ghostty 1.4 compresses the scrollback whenever nothing is happening in the terminal. According to the developers, it then needs 70 to 90 percent less memory. Most people won’t notice that in everyday use. But if you want to squeeze the most out of a weaker machine, or you work with huge files and output, you also need a terminal that goes easy on resources.

At the same time, Ghostty now remembers more. The project raises the scrollback per terminal from 10 to 50 MB, so you can scroll back a lot further. When you scroll or search, Ghostty quietly decompresses the data again. Compression is available on 64-bit Linux and macOS. If you don’t want it, turn it off with scrollback-compression = false. By the way, Ghostty itself tells you what an option does.

Sharper text with fractional scaling

If your monitor runs at 125 or 150 percent scaling, you’ll probably like the next change. Until now, text in Ghostty looked slightly blurry at those values. With 1.4, text and box-drawing characters are crisp there too. To get there, the project rewrote how Ghostty draws on Linux. Tearing, the kind you might see while scrolling, should be pretty much gone as well.

The rewrite comes at a price, though. Ghostty 1.4 needs at least GTK 4.18 and libadwaita 1.7, which is no problem on an up-to-date Arch Linux. Ubuntu 24.04 LTS, on the other hand, ships versions that are too old. If you’re still on that LTS, the developers recommend sticking with an older Ghostty release or using a Flatpak.

Moving splits with the mouse

If you work with splits a lot, you’ll like this one: you can now rearrange splits with the mouse. Move the pointer to the top edge of a split, and a handle with three dots appears. Drag it onto another split, and a blue area shows where it will land. This works across tabs and windows, too. Running programs, output and the working directory move along with it.

That way, you can move a running htop from the bottom to the left without restarting it. On Linux, though, you can only drop a split onto another split, not into a new tab or window of its own. Whole tabs, on the other hand, can be moved to a new window through the command palette. If the handle bothers you, hide it with drag-handle = never.

Naming windows and a fully localized command palette

With several Ghostty windows open for different projects, it’s easy to lose track. That’s why you can now rename windows from the menu, say to “Blog” or “Server”. Leave the field in the dialog empty, and Ghostty goes back to the automatic title. The command palette is now fully translated as well. In my German setup, it shows every action in German and, where there is one, the matching shortcut.

Handy if you like a drop-down terminal in the style of Guake: the new command ghostty +toggle-quick-terminal shows and hides Ghostty’s quick terminal, for example from a shortcut of your own. That works on Plasma, Sway or Hyprland, but not on GNOME, which lacks the interface it needs. Also new: you can choose the screen the quick terminal appears on.

Images in the terminal and more speed

Programs can show images in Ghostty through the Kitty graphics protocol. With 1.4, Ghostty supports the protocol completely, including animated images, and loads large graphics noticeably faster. Terminal file managers such as Yazi or Tfm benefit from this, since they show images right in their preview. That way you find the right photo without opening an image viewer first.

Ghostty has become faster elsewhere, too. According to the project’s measurements, the terminal processes plain text 5.7 times as fast as before. You’ll notice that when a build or a log writes lots of lines to the terminal. Resizing the window with a long scrollback is supposed to be up to six times quicker. Some of the other numbers in the release notes only apply to macOS, though.

No more error messages over SSH

If you log in to a server over SSH from Ghostty, you may know errors like “missing or unsuitable terminal: xterm-ghostty”. Programs like htop or nano then don’t work properly on the server, because the server doesn’t know Ghostty. New is the command ghostty +ssh, which hands the server the information it needs when necessary. If that fails, it falls back to a compatible setting.

$ ghostty +ssh user@server

There’s also a security reason to update. Ghostty 1.4 fixes ten vulnerabilities. Among other things, crafted graphics commands could crash the terminal. On top of that, you could trick the paste protection, which is supposed to warn you before multi-line commands run by accident right away. Some of the vulnerabilities only affect macOS or Zsh as your shell, though.

Watch out for shortcuts and copying

A few changes break old behavior. On Linux, Ctrl+Shift+Page Up and Ctrl+Shift+Page Down now move tabs. To jump to the previous or next prompt, use Ctrl+Shift+Up and Ctrl+Shift+Down instead. Programs running in the terminal no longer see these key combinations. If you need them there, remove the binding again with unbind in the configuration.

If you’ve set Ghostty to copy selected text automatically, you should also take a look at your configuration. With copy-on-select = clipboard, the selection now only ends up in the regular clipboard. If you want to keep pasting it with the middle mouse button as before, change the value to both. What the middle mouse button pastes is set by middle-click-action.

libghostty: Ghostty is coming to other programs

In the discussion on Hacker News about the release, Mitchell Hashimoto points to libghostty. The library contains Ghostty’s core, meaning everything that makes up a terminal on the inside. Other programs can use it instead of writing their own terminal. Hashimoto jokingly calls Ghostty itself “just a glorified tech demo for libghostty”.

For you, this means Ghostty’s technology is gradually showing up in other programs. The terminals in JetBrains’ IDEs already run on it, and a switch is being discussed for Neovim. And a KDE developer is building a new terminal based on libghostty that could eventually succeed Konsole. Version 1.0 of the library is expected in the next few months.

Installation

On Arch Linux, Ghostty is in the Extra repository, though at the time of writing still at version 1.3.1. Version 1.4 should follow there in the next few days. Besides the terminal itself, you should also install the shell integration and the terminfo. If you don’t want to wait, the AUR has the package ghostty-nightly-bin, which I also used for the screenshots in this article.

$ sudo pacman -S ghostty ghostty-shell-integration ghostty-terminfo

The project itself doesn’t provide ready-made packages for Linux; that’s left to the distributions. Ubuntu has shipped Ghostty in its official repositories since 26.04, though not always in the latest version. For Fedora, there’s a COPR repository, plus a Snap, an AppImage and a Debian package from the community. Ghostty’s installation guide gives you an overview.

All in all, Ghostty 1.4 is a well-rounded update in my opinion. As someone who switched from Tilix, I’m glad to see a modern tiling terminal on a GTK base being developed so actively. If you’d rather stay closer to how Tilix works, take a look at Rutile as well. You’ll find all changes in the release notes. Which terminal do you use?

☕ 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 start page simply froze Epiphany solid. Afterwards, the journal held a core dump of the web process, and systemd had logged a memory peak of 5.8 GB. For a news site with a handful of cards, that’s a bit much in my opinion. Restarting didn’t help either: Epiphany dutifully restores the PlanetFOSS tab and promptly chokes on it again.

Following the trail

A look at the package history gave the first clue: on October 7, Arch Linux had updated WebKitGTK, the browser engine behind Epiphany, to version 2.54. The browser itself was quickly off the hook. MiniBrowser, a bare-bones test browser that ships with WebKitGTK, ballooned to several gigabytes within seconds on the PlanetFOSS start page. A plain example page, on the other hand, gets by with 170 MB.

The trail leads to the star

An AI gave me a hand with the debugging, but narrowing things down was good old process of elimination. Without JavaScript, the page still hung. Without the stylesheet, it ran just fine. After that, one style rule after another got the boot until the culprit was clear: backdrop-filter. It blurs the background behind an element and creates the popular frosted-glass look.

PlanetFOSS uses the effect in several places, but mostly on the small bookmark stars in the top left corner of every article card. The start page has 55 of them, plus eight news cards and ten play icons on the videos. Each of these elements gets its own frosted-glass layer. In those numbers, WebKitGTK 2.54 apparently buckles. Tiny star, massive impact.

To double-check, I built a test page full of cards, each with one small frosted-glass element. With ten to 14 cards, memory stayed in the green. With 18 cards, around one gigabyte was already taken, and from 22 cards on, usage shot up to seven or eight gigabytes. So things tip over somewhere around 20 layers, although the exact limit is hard to pin down.

The interesting part: the blur itself isn’t to blame at all. Frosted glass without any blur, or a simple grayscale filter, bloats WebKitGTK just the same. So the problem lies in how the new version manages these layers. Turning off the engine’s hardware acceleration does keep the test page lean. That’s no fix, though, since I can hardly tell my visitors how to launch their browser.

Firefox and Chrome couldn’t care less

That leaves the question of whether only WebKitGTK is affected. So I loaded the same copy of the start page in different browsers, once with the old and once with the new design, and measured memory usage each time. I did this on my Arch notebook and in a virtual machine running Ubuntu 26.04. Images and text were identical in every run.

The result is clear. Firefox and Chrome show practically the same usage before and after. Even Ubuntu’s older WebKitGTK 2.52 stays perfectly calm at around 680 MB. Only version 2.54 explodes: on my notebook, memory usage climbed to 9.8 GB in 40 seconds. After reworking the page, it was a mere 300 MB.

In the VM, Epiphany ran as a Flatpak, which brings the new engine along. There, the browser ballooned to 4.3 GB within a minute, until only 300 MB of the roughly 5 GB of RAM were left. In an earlier run, the tab threw in the towel entirely: Oops! Something went wrong while displaying this page. With the new design, it stayed at 721 MB.

Opaque background instead of frosted glass

The fix on the PlanetFOSS side is unspectacular. Stars, news cards, and play icons now do without frosted glass, and their background is simply a little less transparent instead. You’ll really only notice the difference if you put both versions side by side and look very closely. For a few gigabytes less memory hunger, that’s more than a fair trade in my opinion.

The change has been live for a few days, and MiniBrowser once again gets by with 213 MB on the real start page. I kept the frosted-glass effect in the pop-out section bar and on the source links in the lead story. That’s only a handful of layers, and they don’t throw WebKit off balance. linuxundich.de also uses the effect in just two places and was never affected.

All in all, the problem clearly lies in WebKitGTK 2.54 and not in my stylesheet. Presumably every page that uses enough elements with backdrop-filter is affected. So my advice to everyone who builds websites: go easy on the frosted glass and load your site in Epiphany every now and then. I’ve filed a bug report with a test case in the WebKit Bugzilla. Hopefully I didn’t kill anyone’s browser session.

☕ 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.

Why Sonos S1 still needs SMB1

I still have two Play:3, a Play:1, and a Connect:Amp on my network. All of them run the S1 software, for which Sonos only ships bug fixes these days. The speakers don’t just play streams, they also play my music collection from the server. According to a discussion in the Sonos forum, however, the S1 devices only have enough resources for SMBv1 – the old hardware simply can’t do more.

Samba, on the other hand, retired the old protocol a long time ago. Since version 4.11, server min protocol defaults to SMB2_02, and according to the Samba project, NTLMv1 authentication has been disabled since version 4.5. The usual guides turn both back on globally with two lines. Sure, the speakers play after that, but they’re not the only ones who get the door held open for them.

If you run an S2 system, you’re off the hook. Sonos added SMBv2 and SMBv3 there with version 13.4.1 in December 2021 and no longer speaks SMBv1 at all. S2 users can leave Samba’s defaults alone. The rest of this article is for everyone who, like me, is still attached to their old speakers and doesn’t want to throw them out over a protocol.

What’s wrong with the quick fix

Samba can only allow SMB1 for the whole server, not for individual shares or devices. Ever since WannaCry exploited a hole in Microsoft’s SMB1 in 2017 at the latest, the protocol has been considered legacy baggage, and NTLMv1 makes it easy for attackers to crack captured logins. If the speaker then logs in with your regular user on top of that, it’s your main password of all things that travels across the network using the weakest method available.

On top of that come lines that people like to copy along while they’re at it. With wide links and allow insecure wide links, Samba follows symlinks even when they point outside the share. Often the entire data directory is shared writable, too. Sure, from the outside a little home server like this is usually locked down. But the same LAN is also home to TVs, smart plugs, and speakers whose software you have no control over.

A dedicated user just for Sonos

The most important step is a dedicated user that exists only for the speakers and isn’t allowed to do anything else. It needs neither a home directory nor a shell; Samba only knows it for logging in. You set the password once and don’t use it anywhere else, because with NTLMv1 you should consider it semi-public. Creating it from scratch takes two commands:

$ sudo useradd -r -M -s /usr/bin/nologin sonos
$ sudo smbpasswd -a sonos

If you already have a user the speakers log in with, trim it down with usermod. It loses its shell and gets / as its home directory and a locked Unix password. Logging in to Samba uses the separate password from smbpasswd and keeps working regardless. If your speakers have been using your regular user so far, however, you’re better off creating a new one:

$ sudo usermod -s /usr/bin/nologin -d / sonos
$ sudo passwd -l sonos

The smb.conf

The configuration allows SMB1 and NTLMv1 but fences in everything around it. Samba only listens on the LAN interface and not on Docker bridges or VPN tunnels. Guests are kicked out, there are no printers, and every share gets a list of users who are allowed in. You’ll of course have to adapt the name of the network interface (enp0s25 on my machine) and the paths to your system:

[global]
   workgroup = WORKGROUP
   server string = bender
   server role = standalone server

   # Sonos S1: nur SMB1 + NTLMv1
   server min protocol = NT1
   server max protocol = SMB3
   ntlm auth = ntlmv1-permitted

   # nur LAN und lokal, nicht auf den Docker-Bridges
   interfaces = lo enp0s25
   bind interfaces only = yes

   map to guest = never

   # keine Drucker
   load printers = no
   printing = bsd
   printcap name = /dev/null
   disable spoolss = yes

[homes]
   browseable = no
   writable = yes
   valid users = %S
   invalid users = sonos

[musik]
   path = /data/musik
   browseable = yes
   read only = yes
   valid users = sonos anna ben lena

[data]
   path = /data
   writable = yes
   valid users = anna ben

By the way, ntlmv1-permitted is just the more descriptive name for the old yes. The [musik] share (German for music) is read-only; sonos and the family, here anna, ben, and lena, are allowed to read it. Even if someone cracks the speaker’s login, all they get is the music. Only anna and ben can access [data], wide links doesn’t appear anywhere, and symlinks therefore stay within their share.

The line invalid users = sonos under [homes] matters, too. This share offers every user their home directory, and for the speaker user that’s the root directory after the usermod above. Without that line, there would be a writable share \\bender\sonos covering the entire system. What actually works there is still governed by file permissions, but directories like /tmp are open to everyone.

If you can’t set up the Sonos library from scratch right now, there’s also an intermediate step without a separate music share. In that case, add sonos to the valid users of the existing share and also set read list = sonos. The speaker can then still read everything the file permissions allow, but can’t write anything. In the long run, though, a separate share is clearly the better choice.

Before you activate the new file, have testparm check it. It complains about typos and unknown options before Samba trips over them. Then restart the service – on Arch it’s called smb, on Debian and Ubuntu smbd. Open connections drop briefly, but mounted shares on your computers usually reconnect on their own:

$ sudo testparm -s
$ sudo systemctl restart smb

The music library in the Sonos app

Finally, add the share as a music library in the S1 app. Open Settings and go to Music Library and Music Library Setup. Enter the share in Windows format as the path, i.e. \\bender\musik, followed by the user sonos and its password. Sonos then indexes the collection, which can take a while for large libraries.

Checking the result

smbstatus shows you whether everything works as intended. The Protocol Version column tells you who is connected with which protocol. Regular computers should keep connecting via SMB3 – my notebook, for example, uses SMB3_11 – and only the speakers show up with NT1. A guest login without a password, on the other hand, should bounce off with NT_STATUS_ACCESS_DENIED when you try it with smbclient from another computer:

$ sudo smbstatus -b
$ smbclient -N //bender/data -c ls

Don’t let the output of the second command mislead you. The line “Anonymous login successful” sounds like an open door, but it only concerns the connection to the server itself, which a client uses to fetch the list of shares, for example. The second line is what counts, because nobody gets into the share itself without a user name and password:

$ smbclient -N //bender/data -c ls
Anonymous login successful
tree connect failed: NT_STATUS_ACCESS_DENIED

On my server it looks like this: The speaker in the bedroom reads as sonos via NT1, while the notebook is connected with SMB3_11 and a signed connection. That’s exactly how it should be, because the old protocol stays limited to the devices that can’t do anything else. The other speakers only show up while they’re actually accessing the library:

$ sudo smbstatus -b

Samba version 4.25.0
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing              
----------------------------------------------------------------------------------------------------------------------------------------
732192  sonos        sonos        192.168.0.60 (ipv4:192.168.0.60:38427)    NT1               -                    -                    
711090  anna         anna         192.168.0.191 (ipv4:192.168.0.191:52826)  SMB3_11           -                    partial(AES-128-CMAC)

And in the long run?

Of course, I’m still not entirely happy with SMB1. My server already runs bonob, which brings Navidrome into the Sonos app as a music service. If the music comes through that, no speaker needs a Samba share anymore, and SMB1 could go for good. But if you can’t do without Sonos’s built-in library, the restricted setup is a good compromise in my view.

All in all, the clean approach only costs you one user and a few extra lines in smb.conf. The speakers play just as well as with the quick fix, except that they no longer offer a path to the rest of the server. How did you hook up your old Sonos speakers? Is SMB1 still running on your network, too, or did you switch to S2 long ago?

☕ 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.