Okay, here we go…
Services on embassyOS
As of the current version of embassyOS, every service is packaged in a container that’s hosted using Docker. This includes not only Syncthing, but even the web-based File Browser. From the Service Container section of the user manual:
Each service is compartmentalized into its own “container.” At this time, this normally means a Docker container, however embassyOS is modular and other options will be available soon. There are several reasons for doing this, including security, ease of use, and maintenance.
The enhanced security comes with a price – a more complicated setup.
A container provides an isolated environment for an app to run in. It’s like putting a RC toy in something so that it can’t run out of control. For it to be fun, it has to be the right container for the right toy (e.g., a sailboat in a sandbox vs. a truck in a pool).
In order for an app to access resources outside of its container, suitable connections are required. Likewise, for a toy boat to sail from one pool to another, the best option is a channel of water between the pools. However, that same channel of water would be practically useless for a toy truck.
You’ve been using the web-based File Browser, and possibly network share(s), to upload files to your Embassy One server. Now you want to set up a peer-to-peer file sync between an Embassy One server, a MacBook, an Android smartphone, and an iPhone using Syncthing.
But in order for that to work, the File Browser and Syncthing must be able to access the same files and folders (i.e., a suitable channel must connect the two isolated services).
Syncthing
The good news is that based on the screenshots you’ve posted so far, there doesn’t appear to be anything wrong with Syncthing or its settings. Note how both the Syncthing folders ActiveClientsSyncT and NOTES share the same base path of /mnt/filebrowser/syncthing:
None of the earlier screenshots indicated that Syncthing is wrong when it said there were no files and folders found under /mnt/filebrowser/syncthing/NOTES.
Share Management
Perhaps the original screenshot was truncated, but the files and folders listed under the Share Management tab in the File Browser service looks incomplete:
Focusing just on the Syncthing-related items:
/syncthing/ActiveClientsSyncT/.stfolder/CDC New Masking Guidelines.jpg
/syncthing/ActiveClientsSyncT/CDC New Masking Guidelines.jpg
/syncthing/ActiveClientsSyncT/Mario Rubio.odt
There’s a .jpg and .odt file matching Syncthing’s scan results of 2 files and 0 folders for Syncthing folder ActiveClientsSyncT (Syncthing doesn’t count its own .stfolder marker).
So, where is /syncthing/NOTES?
(I suspect that the folder configured in Syncthing isn’t actually the same one you’ve been adding files and folders into via File Browser.)
embassyOS
I downloaded embassyOS for x86 to take a closer look at how it works. Having used a number of NAS-oriented software appliances, while embassyOS doesn’t have as many features and more seamless UI as OpenFiler, OpenMediaVault, TrueNAS, Unraid, and others, it’s still pretty good for its intended audience.
It only took a few clicks to install File Browser and Syncthing, then just a few minutes more to set up folders to sync with a Linux workstation.
Output from docker container list and docker image list:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b3bb2e324819 start9/syncthing/main:1.22.1.1 "tini entrypoint.sh" 3 minutes ago Up 2 minutes 8384/tcp, 8384/udp, 22000/tcp, 22000/udp syncthing.embassy
a993a6f79ad3 start9/filebrowser/main:2.22.4.1 "docker_entrypoint.sh" 34 minutes ago Up 34 minutes filebrowser.embassy
REPOSITORY TAG IMAGE ID CREATED SIZE
start9/x_system/compat latest 050a7c7591cb 2 weeks ago 92.3MB
start9/x_system/utils latest c1976a03f9f8 3 weeks ago 24.8MB
start9/syncthing/main 1.22.1.1 f8d826fafb31 3 weeks ago 45.7MB
start9/filebrowser/main 2.22.4.1 c1d7532fedbf 4 weeks ago 43.3MB
start9/x_system/binfmt latest 3f7fd8db05af 4 months ago 60.2MB
Output from df -h:
Filesystem Size Used Avail Use% Mounted on
udev 469M 0 469M 0% /dev
tmpfs 98M 1.1M 97M 2% /run
overlay 489M 366M 123M 75% /
/dev/sda2 6.8G 2.9G 3.7G 44% /media/embassy/next
tmpfs 489M 160K 489M 1% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
/dev/sda1 1022M 49M 974M 5% /boot
/dev/mapper/EMBASSY_QEVJJSCWNW4O3K43YZRWTUZNTOGBXY4SZZXHL2LPW6FYL4SKQIRQ_main 7.8G 96M 7.3G 2% /embassy-data/main
tmpfs 98M 4.0K 98M 1% /run/user/1000
/dev/mapper/EMBASSY_QEVJJSCWNW4O3K43YZRWTUZNTOGBXY4SZZXHL2LPW6FYL4SKQIRQ_package-data 32G 303M 30G 1% /embassy-data/package-data
/dev/dm-6 9.8G 43M 9.2G 1% /var/lib/docker/devicemapper/mnt/7a0e2efac5f3e5a6b39547772b4a90e98126c90b7b20e85dc8beef2c323930ce
File and folder permissions…
If you were to change your password for the File Browser and then try to log onto Syncthing, it wouldn’t work even if both logins are the same username.
The “admin” user shown in the File Browser is actually unrelated to the actual owner of the files and folders on the drive.
User “admin” is only the web user who uploaded a file or created a folder.
After installing embassyOS with File Browser and Syncthing, I logged onto File Browser as user “admin”, created two directories Music and gadget, then uploaded a MP3 file. Next, I logged onto Syncthing as a different user “admin” and created a Syncthing folder named “Notes” (allowing Syncthing to create a default syncthing directory in the process).
Logging onto embassyOS via SSH, I inspected the directory tree:
root@embassy:# cd /embassy-data/package-data/volumes/filebrowser/data/main/data
root@embassy:/embassy-data/package-data/volumes/filebrowser/data/main/data# ls -l
total 12
drwxr-xr-x 2 root root 4096 Dec 25 23:54 Music
drwxr-xr-x 2 root root 4096 Dec 25 23:55 gadget
drwxr-xr-x 4 start9 root 4096 Dec 26 00:28 syncthing
root@embassy:/embassy-data/package-data/volumes/filebrowser/data/main/data# tree
.
|-- Music
| `-- I_Can't_Go_For_That.mp3
|-- gadget
`-- syncthing
`-- Notes
4 directories, 1 file
From the shell terminal output above:
- The ownership of the
syncthing directory created by the Syncthing container is user “start9” and group “root”, while the directories Music and gadget created by the File Browser container are owned by root:root.
- None of the files and folders are group writable.
The file/directory permissions mean that Syncthing cannot write/delete items created by File Browser, but File Browser can write/delete items created by Syncthing.
/embassy-data/package-data/volumes/filebrowser/data/main/data is mapped to /mnt/filebrowser inside the File Browser and Syncthing containers (in technical terms, it’s a bind mount using the Linux kernel’s OverlayFS filesystem module).
Screenshots showing each stage of the setup:
Installing File Browser…
Installing Syncthing…
Creating folders and uploading files with File Browser…
Syncthing setup…
Thoughts…
It can be a lot to digest. I think the best thing to do is to put aside Syncthing for the time being, step back, and review the user manual (https://docs.start9.com/latest/user-manual) to get a better idea of how embassyOS works. It’ll be time well spent because you’re trying to do way too much all at once.
Although using embassyOS doesn’t require Docker skills, having a basic understanding of how Docker works is helpful – Getting Started With Docker Containers: Beginners Guide
There are also important security considerations after installing the File Browser, Syncthing and other network services in embassyOS. For example, did you know that embassyOS automatically makes network services publicly accessible on the internet via unique .onion addresses without the need to reconfigure your firewall(s)? It’s not necessarily bad, but it does require some attention.
