This post addresses how to keep two directories in sync on a single Linux machine using Syncthing (avoiding things like rsync, unison, etc.). This is particularly useful if you have two logseq graphs on your system and you want to share a directory underneath your pages directory between both.

Setting up the mount

• Requirements:
  • util-linux v2.39
• Preparation:
  • sudo useradd -m USERNAME_helper
  • Make note of the user id and group id (usually they are the same number)
• Testing the mount one-time:
  • sudo mount --bind -oX-mount.idmap=b:1000:1001:1 /home/USERNAME/shared_logseq /home/USERNAME_helper/shared_logseq
  • This assumes your main user has uid/gid 1000 and the helper account has uid/gid 1001
  • If the target directory does not yet exist, create it first
  • If this works correctly, you can unmount it and start setting up the permanent mount as follows
• Setting the mount permanently in /etc/fstab:
  • /home/USERNAME/shared_logseq /home/USERNAME_helper/shared_logseq none defaults,user,bind,X-mount.idmap=b:1000:1001:1 0 0
  • The b flag creates both user and group mapping
  • Mount the directory: sudo mount /home/USERNAME_helper/shared_logseq

Setting up Syncthing

• Let systemd launch an extra syncthing permanently:
  • sudo systemctl enable --now syncthing@USERNAME_helper
• Check the logs and find the port number used by syncthing:
  • sudo systemctl status syncthing@USERNAME_helper
• Open the syncthing with a browser and configure it to disable NAT, global discovery and relays
• Connect your Syncthing instances together as usual, and share the folders between the syncthing instances

Git has the useful function git log --first-parent that will show your branch without the commits introduced by merge commits. Sometimes I want the opposite (i.e., understand which commits were added by a merge), and there I find the following command useful: git log ^HEAD^ HEAD. This command will print the commits that are not (an ancestor of) the commit on your branch before the merge commit. Effectively, it will only show the commits brought in by the merge commit.

A more succinct but less readable version is git log ^@^ @ .

I measured the NUC8i7BEH:

• Fully idle in Linux: 4W
• Lightly loaded in Linux (running 1 VM of Home Assistant and a few containers): ~10W

When you wish to change the default link sharing type for Teams channels in Office/Microsoft 365, the SharePoint admin interface is lacking the options to configure for this. This is now also mentioned in the SharePoint documentation since this GitHub PR, but the updated SP documentation does not go into detail on the exacts steps to take. To bridge the gap, this post will provide a script that you can use.

The following code will solve this problem by looping through all SharePoint sites and setting the default link sharing option to “people with existing access”, which was my use case. You can tweak the script to your requirements.

$admin_site_url = "https://<YOUR_SITE>.sharepoint.com"
 
Connect-SPOService -Url $admin_site_url
$site_collections = Get-SPOSite -Limit All
  
Foreach ($site in $site_collections)
{
    Write-Host $site.Url
    Set-SPOSite -identity $site.Url -DefaultLinkToExistingAccess $true
}

Joplin-server is a nice solution to sync multiple Joplin instances. In fact, you can even use it to sync only a subset of your notebooks to certain devices by providing different user accounts for those devices and using the notebook-sharing functionality in Joplin-server.

I did find in Joplin-server that syncing shared encrypted notebooks didn’t always succeed in sharing the master keys. One workaround — if you own all the accounts, of course — is to use a single master key with a very strong password.

To achieve this:

1. Close your secondary Joplin client with the option Joplin->Settings->Sync (advanced)->’delete local data and re-download from sync target’;
2. Connect to the postgresql database with the credentials that you used to set it up (e.g. check your .env if you used docker-compose). Go to the table ‘items’;
3. Inspect the stored master keys, e.g. [...] content LIKE '%activeMasterKeyId%'(should only hit for ‘info.json’);
4. Copy the value of the content and content_size fields of your primary account to those of your secondary account (you can determine primary and secondary by comparing the keys with those found in Joplin->Settings->Encryption);
5. On the secondary Joplin system, edit the database in ~/.config/joplin-desktop/database.sqlite and also insert the primary master key data into table ‘settings’ -> field ‘syncInfoCache’;
6. Restart your secondary Joplin, and it will download your notes and use the right master key. No more yellow warning banners in the apps.