Same symptom, completely different machine

I already wrote about the remount script I built for my NixOS desktop … clearing stale network mount units through systemd when a share drops.

This is the other half of that same story, except this one lives on JackSparrow2 itself (the T620 server) and fixes a genuinely different failure, even though the symptom looks identical from the client side: a share that used to work suddenly doesn’t.

Getting it onto the actual server

scp qnap-remount.sh tolga@192.168.0.xxx:~/
ssh tolga@192.168.0.xxx
sudo mv ~/qnap-remount.sh /usr/local/bin/qnap-remount
sudo chmod +x /usr/local/bin/qnap-remount

Copied over, dropped into /usr/local/bin without the .sh extension so it reads like a proper installed command rather than a script sitting in a folder somewhere.

The actual root cause this one fixes

The NixOS script deals with the client side going stale. This one deals with something happening between JackSparrow2 and the QNAP behind it … a hiccup in the QNAP’s own NFS export table, or Samba on the T620 holding onto file handles that pointed at a mount that’s since dropped and come back differently. Different layer, different fix needed.

Checking the QNAP is even reachable before doing anything

nas_ip="192.168.0.xxx"
step "Checking QNAP is reachable"
if ! ping -c1 -W2 "$nas_ip" >/dev/null 2>&1; then
    err "QNAP ($nas_ip) is not responding to ping."
    exit 1
fi

No point trying to fix mounts to a device that’s genuinely offline … this exits immediately with a clear message instead of grinding through umount/remount attempts against a dead target and producing confusing output.

Only touching mounts that are actually stale, not everything

for d in "$data_root"/*; do
    [[ -d "$d" ]] || continue
    if mountpoint -q "$d"; then
        if ! ls "$d" &>/dev/null; then
            warn "$d looks stale, forcing unmount"
            sudo umount -f -l "$d" 2>&1
        fi
    fi
done

This is the important bit … it checks each mount two ways, not one. mountpoint -q confirms it’s genuinely mounted at all, but that alone doesn’t prove it’s working. ls "$d" is the real test … a stale NFS handle will still show as mounted while completely failing to list its own contents. Only mounts that fail both checks get force-unmounted; anything actually healthy gets left alone.

Since this box has an fstab, the remount step is simpler

Unlike the NixOS side, JackSparrow2 runs plain Fedora with a real /etc/fstab, so remounting is the standard, boring command:

step "Remounting via /etc/fstab"
sudo mount -a

The step that isn’t obvious until you’ve actually hit this

step "Restarting Samba (smbd holds cached handles from before the remount)"
sudo systemctl restart smb nmb

This is the part that cost me real time the first few times this happened. Remounting the underlying NFS path from the QNAP doesn’t automatically mean Samba picks up the fresh mount … smbd can keep serving through a cached file handle that points at the old mount instance, meaning clients connecting via Samba still see a broken share even though the NFS mount underneath is genuinely fine again. Restarting smb/nmb forces it to re-establish everything fresh against the now-working mount.

Knowing when the script genuinely can’t fix it

if [[ "$failed" -eq 0 ]]; then
    msg "All shares recovered."
else
    warn "Some shares are still broken."
    echo "  This usually means the QNAP's own NFS export table needs a reboot:"
    echo "    ssh admin@${nas_ip}"
    echo "    cat /proc/fs/nfsd/exports    # if empty, that's the problem"
    echo "    Control Panel -> System -> Power -> Restart"
fi

I added this after actually hitting the case where the problem wasn’t on JackSparrow2’s side at all … the QNAP’s own export table had gone empty, which no amount of remounting or restarting Samba on the client side can fix, because there’s nothing valid being exported to reconnect to. The script tells you exactly where to look instead of silently failing or, worse, looking like it succeeded when it didn’t actually fix anything.

Running it

sudo qnap-remount

One command, checks the QNAP is alive, only touches mounts that are genuinely broken, remounts through the real fstab, restarts Samba so cached handles don’t linger, and tells me plainly if the real problem is actually on the QNAP’s end rather than pretending it fixed something it didn’t.

Two scripts, same instinct

Different machine, different mount technology, different actual root cause … but the same underlying lesson both times: don’t assume a mount reporting as “active” means it’s actually working. Check by listing real content, every time, and only act on what’s genuinely broken.

scp qnap-remount.sh tolga@192.168.0.xxx:~/
ssh tolga@192.168.0.xxx
sudo mv ~/qnap-remount.sh /usr/local/bin/qnap-remount
sudo chmod +x /usr/local/bin/qnap-remount

scp ~/Downloads/qnap-remount.sh tolga@192.168.0.xxx:~/

cat /usr/local/bin/qnap-remount

#!/usr/bin/env bash
# =============================================================================
#  qnap-remount.sh
#  Tolga Erok
#  Version : 1.0
#  Date    : 11 Jul 2026
#
#  Clears stale NFS mounts from QNAP (192.168.0.xxx) on JackSparrow2 and
#  restarts Samba so shares re-serve cleanly. Covers the exact failure
#  pattern hit repeatedly today: stale file handles after a QNAP export
#  table hiccup, and smbd holding broken cached paths afterward.
#
#  Does NOT touch the QNAP itself -- if `cat /proc/fs/nfsd/exports` on the
#  QNAP is empty, that's a server-side export table problem and needs a
#  full QNAP reboot (Control Panel -> System -> Power -> Restart), not
#  anything this script can fix from the client side.
# =============================================================================

set -uo pipefail

red='\e[31m'; grn='\e[32m'; yel='\e[33m'; cyn='\e[36m'; rst='\e[0m'; bld='\e[1m'

msg()  { echo -e "${grn}${bld}[  OK  ]${rst} $*"; }
info() { echo -e "${cyn}${bld}[ INFO ]${rst} $*"; }
warn() { echo -e "${yel}${bld}[ WARN ]${rst} $*"; }
err()  { echo -e "${red}${bld}[ FAIL ]${rst} $*"; }
step() { echo -e "\n${yel}${bld}  ──► $*${rst}"; }

nas_ip="192.168.0.xxx"
data_root="/mnt/data"

step "Checking QNAP is reachable"
if ! ping -c1 -W2 "$nas_ip" >/dev/null 2>&1; then
    err "QNAP ($nas_ip) is not responding to ping."
    echo "  Check it's powered on and on the network before continuing."
    exit 1
fi
msg "QNAP responding"

step "Current NFS mounts from QNAP"
mount | grep "$nas_ip" || warn "No NFS mounts from $nas_ip currently active"

step "Unmounting anything stale"
for d in "$data_root"/*; do
    [[ -d "$d" ]] || continue
    if mountpoint -q "$d"; then
        if ! ls "$d" &>/dev/null; then
            warn "$d looks stale, forcing unmount"
            sudo umount -f -l "$d" 2>&1
        fi
    fi
done

step "Remounting via /etc/fstab"
sudo mount -a

step "Restarting Samba (smbd holds cached handles from before the remount)"
sudo systemctl restart smb nmb
msg "Samba restarted"

step "Verifying each share"
failed=0
for d in "$data_root"/*; do
    [[ -d "$d" ]] || continue
    name=$(basename "$d")
    if ls "$d" &>/dev/null; then
        msg "$name — accessible"
    else
        err "$name — still not accessible"
        failed=1
    fi
done

step "Result"
if [[ "$failed" -eq 0 ]]; then
    msg "All shares recovered."
else
    warn "Some shares are still broken."
    echo "  This usually means the QNAP's own NFS export table needs a reboot:"
    echo "    ssh admin@${nas_ip}"
    echo "    cat /proc/fs/nfsd/exports    # if empty, that's the problem"
    echo "    Control Panel -> System -> Power -> Restart"
fi

sudo tee /etc/ssh/sshd_config.d/keepalive.conf << 'EOF'
ClientAliveInterval 60
ClientAliveCountMax 3
EOF

sudo systemctl restart sshd