simon.schönbeck.dk

  • Google Earth – Another instance of this application is already running

    Being unable to launch Google Earth Pro because it thinks it is already running seems to be happening frequently for me. I am using the Flatpak version if it matters.

    Despite killing the application there is still a lock file lingering preventing Google Earth Pro to launch. The error message is specifically:

    Google Earth
    Another instance of this application is already running.

    To launch Google Earth again you need to delete this stale lock file which is inside your user directory:

    rm -v $HOME/.var/app/com.google.EarthPro/.googleearth/instance-running-lock

    Once gone Google Earth Pro will run again without complaining.

  • Fedora Thunderbird Flatpak wrong file association

    I struggled for a while with jpg image files not properly opening with the “System Handler” in Thunderbird. Despite changing the file association setting back to “Always ask” to reset it, the wrong application opened the images.

    Usually one would just select another application in the list of applications but since it is a Flatpak the sandbox restricts access and none where displaying.

    Fiddling around I deleted the second order in the chain where Thunderbird Flatpak searches for the right application to open (after the handlers.json):

    rm ~/.var/app/net.thunderbird.Thunderbird/config/mimeapps.list

    After a restart the “System Handler” finally opened up the correct application as it was using the third level in the lookup chain, the XDG Desktop Portal, which gracefully forwarded the request to Loupe in this case.

  • Static ARP Ubiquiti EdgeOS

    There are times when one needs to reach a certain device on the network and cannot as multiple devices have the same IP address. This should in theory not happen but it does in networks where people can freely connect devices themselves. If the device has a static IP address which another device already has, it is nearly impossible to reach it to reconfigure it remotely as packets would end up on the wrong device. This where a static ARP entry can smooth out things forcing the router to only send packets to that single device of one’s choice

    sudo arp -s 192.168.0.1 e4:ea:b4:08:a8:32 -i eth1

    This tells the router that “192.168.0.1” is at MAC “e4:ea:b4:08:a8:32” and will stop it broadcasting ARP requests; it just sends packets directly to that MAC.

    When done simply delete it again:

    sudo arp -d 192.168.0.1 -i eth1


    After that, the router will go back to the normal ARP behaviour of broadcasting ARP requests instead of using the fixed MAC.

    If you run show arp eth1 after deletion, you should see the static entry removed.

  • Rapidly reduce the size of a PDF

    I am sure you have been there before, trying to submit an important form and your PDF with high resolution scans is too big to be accepted.

    As you probably entered a lot of other data, you do not want to repeat the entire form if the page times out (which they seem to always do!).

    This is an instant one-liner that substantially reduces the PDF size without much quality degradation (my PDF went from 8.9 MiB to 1.1 Mib):

    gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 \
    -dPDFSETTINGS=/ebook \
    -dNOPAUSE -dQUIET -dBATCH \
    -sOutputFile=output.pdf input.pdf

    There are tons of options and parameters in Ghostscript to play with if you are interested, but the above will work for a start. Simply edit the input.pdf and output.pdf paths/files.

  • Toolbx mount access from host on Fedora Kinoite

    Since Toolbx mounts are running in different namespaces than the host, the mounts cannot be accessed from the latter. I tried many workarounds to see if it really was possible to get around this limit. After some time I decided that using the network stack was probably a better solution to communicate between Toolbx and host.

    In my particular case I never do any layering but instead try to use Flatpak, Toolbx, or even a Boxes virtual machine for any specific software not included in the base layering.

    I needed to run restic to access some documents on a remote restic repo backup. Since restic is not included I had to use Toolbx for this task. Restic uses FUSE to mount the remote end on the local system. In an ideal world I could just have opened this mount in Dolphin to search and open the needed documents. However due to the namespaces difference this mount just shows empty on the host.

    A really quick and dirty solution is to simply use rclone and its webdav option, then Dolphin just opens the webdav address with no issues. Yes, there is a tiny performance hit, but the speed and easy execution greatly makes up for this:

    restic mount ~/remote-restic

    Now that the mount is working from Toolbx itself run rclone to serve it over the network:

    rclone serve webdav ~/remote-restic --addr :8080 -L

    That is all! Now simply open Dolphin and paste the webdav address and there you have your Toolbx mount visible from the host:

    dav://127.0.0.1:8080

    Please note that this is not only for restic but can be used with any mount type like sshfs or even another rclone mount like S3.

    Is it not ironic… using a 1990s protocol (WebDAV) to solve a 2026 container problem!