If you are running Syncthing on macOS, you may see a menu-bar pattern line this:
See also Syncthing forum issue 24351 which was closed without an answer. Same problem.
I don't claim to understand Syncthing's internals but this condition appears to mean that there is a mismatch between the API keys in these two locations:
Each year as Apple's World Wide Developer Conference (WWDC) approaches, I start to think about upgrading macOS to the version that was released at WWDC the previous year. I reckon that's a good way of minimising your pain and suffering, not to mention giving developers a chance to patch things that got broken when the API goal-posts moved.
The end of May 2025 was when I decided to upgrade both a 2019-era Intel iMac and an Apple M2 MacBook from Sonoma 14.7.1 to Sequoia 15.5.
Aside from the seven fractions of eternity that macOS updates seem to demand these days, it all seemed to go swimmingly. The only explicit grizzle was from Carbon Copy Cloner, which wanted a later version (on my to-do list).
Proxmox-VE is great. You can spin-up a Debian guest in a trice, and then spend endless hours tinkering away getting everything working just the way you want. You declare yourself happy and move on to other things.
Until…
Days, weeks or months later you hit a problem when your guest OS runs out of disk space. You think back to the moment when you picked the guest's disk size. And you realise that you - to borrow the words of the Grail Knight in Indiana Jones and the Last Crusade - "chose poorly".
You think, "surely auto-resizing should be possible". You Google. You find some hints that ZFS might've been a solution but, like your original choice of disk size, that, too, would've needed you to "choose wisely" in advance.
IOTstack is a framework for running arbitrary collections of Docker containers using docker compose. The canonical example is the "MING" stack (Mosquitto, InfluxDB, Node-RED and Grafana).
From time to time, someone asks a question like this:
I have read that Docker's "volume mounts" are recommended and/or better than "bind mounts". Why does IOTstack use "bind mounts"?
Unless you understand the differences between Docker's mount types, it's difficult to see why you would want choose one type over the other. This gist attempts to explain the differences between Docker bind and volume mounts, and then answers the question of why IOTstack uses Docker bind mounts exclusively.
When you download a Debian "netinst" ISO and use it to construct a system, you reach an installer screen with the title "Software selection". By default, that screen enables the desktop environment and offers you a choice of windowing interfaces.
If you leave the desktop environment enabled then both Network Manager and the Avahi daemon (multicast DNS) are installed and configured, and the system will boot into the desktop windowing environment.
However, if you disable the desktop environment in the "Software selection" screen then the system will boot to the command-line console and neither Network Manager nor the Avahi daemon will have been installed.
It is not immediately clear why electing not to install a windowing environment should also affect data-communications features. It just does.
A thread on the IOTstack Discord channel can be summarised like this:
The DockerHub nodered/node-red releases page includes tags for both Alpine and Debian-based containers.
At the time of writing (2024-05-06), the support matrix is:
DockerHub tag | latest | latest-debian
A fairly common question from IOTstack users running InfluxDB is how to remove "bad data" from a database?
This gist focuses on InfluxDB 1.8 and the InfluxQL commands needed to operate upon an InfluxDB 1.8 database. You are entirely on your own if you are using InfluxDB 2.x.
The best advice I can give you is to avoid the problem by ensuring that "bad data" never gets into your database in the first place. For example:
The following question appeared on the IOTstack Discord channel. It's the second part of a thread but I'll come back to the first part later:
I'm still struggling with this error. So the instruction says don't assign a password for root during the Debian installation. HOWEVER, the OS image that I'm using already comes with a default root password and I have to enter the default password to continue at the first step. Is there any way to remove this default password? Otherwise, it seems there is no way to continue the installations on this OS...
I don't want to over-sell this but the general thrust of the Unix industry over the last 20-odd years has been to avoid enabling the root account. In more recent times, security gurus, legislatures and best practice have been leading us to a world where there are no default accounts for anything.
Thus, while the general principle mu
This gist is a response to a Discord question asking:
is it possible to add my own container to IOTStack? for example: couchdb
The answer is "yes" and CouchDB is quite a good example to use for a tutorial.
Suppose you have a Node-RED container running but you want to create a test version where you can experiment safely without disturbing the original.
Running multiple instances of a container is something Docker excels at! This tutorial explains how to set it up. It will also help you to understand the differences between containers running in host mode and non-host mode.