site  news  contact

Using Easy Containers

February 16, 2026 — BarryK

Page originally written October 18, 2019
Updated: April 29, 2022: February 16, 2026

Running an application in a container, is a mechanism to achieve isolation from the rest of the system and higher security than if the application were run in the normal way.

There is another web-page which is a technical overview of EasyOS from the user-perspective, including an introduction to Easy Containers (EC):

https://easyos.org/tech/how-easy-works-part-2.html 

...please read the section that introduces Easy Containers, as it provides the basis to understand what follows.

This page is intended to provide addition usage notes. As described in the above link, containerized apps show on the desktop with a "padlock" symbol at top-left of each icon, for example:

img1

Clicking on one of these will run the app in a container. In the case of "www", it will start the Chromium web browser, and it will be just like the normal Chromium (note, earlier versions of Easy may have Firefox builtin). From the user-perspective, you will notice some differences though:

  1. A tiny bit slower to startup.
  2. Open and Save files can only be within the container.
  3. Extensions/add-ons/themes not shared with the system-Chromium.
  4. There may be issues with Internet connection.

You are, in fact, running Chromium in it's own private operating system. Although a container is isolated from the main desktop, it is not perfect isolation. There has to be some interaction, for example to achieve Internet connection via the connection already established on the main desktop.

This required interaction also means potential security weaknesses, however, we try to make it very difficult to break out of a container. So yes, you are considerably more secure.

Regarding point-4, there are sometimes issues with network access from within a container, especially as we attempt to tighten up the security (isolation) settings. Generally, ethernet network connection is better than wi-fi in this regard.

Sharing files with the main desktop

That is point-2 in above list, but that is from the point of view of being inside the container. From the main desktop, you can see inside all of the containers, and do anything that you want in them, including read and write files.

Regardless whether running an app on the main desktop or inside a container, most apps will default to open|save|download to /files, or a sub-folder inside /files. For example, Firefox defaults to download files to /files/downloads.

On the main desktop, the files folder is actually in the working-partition, and /files is a symlink to it. This is explained here:

https://bkhome.org/news/202112/all-downloads-now-to-files-folder.html

However, inside a container there is no access to drive partitions, everything is in RAM, and so is /files. This is for security reasons.

However, by a bit of magic, folder /files on the main desktop is the same as /files inside the container. So, if, for example you download a file while running the web browser inside a container, to make that file available to the main desktop, just save it to /files.

And vice-versa. Though, as already stated, you can read and write anywhere in a container from the main desktop. For example, if the "www" container is running, then if you point the file-manager at /mnt/wkg/containers/www/container, you can access everything inside the container. This is further explained here:

https://bkhome.org/news/202204/some-handy-tricks-with-easy-containers.html

...yes, you are God as far as the containers are concerned!

Run SFSs of other distributions

There is something very nice about SFSget, the SFS downloader and installer, run by clicking the icon labeled "sfsget" on the desktop. That niceness is that you can run any SFSs, regardless of what Linux distribution it is created for.

An app is compiled to work on a particular distribution, and version of that distribution, and may not work on other distributions. This could be due to wrong versions of libraries, or missing dependencies. However, with Easy Containers, that is not a problem.

At the time of writing (February 2026), EasyOS is the "Excalibur" series, version 7.x, but thinking back to 2022:

In April 2022, EasyOS is 3.4.7, the "Dunfell" series. The packages for this series are compiled from source using a fork of OpenEmbedded.

Prior to Dunfell, was the "Buster" series. The Buster series, that started with 2.0, is built with binary packages from the Debian Buster 10 distribution. Buster is now retired.

There is also an even older series of EasyOS, known as the "Pyro" series, version numbers 1.x and the latest is 1.2.3. Easy Pyro is built with packages compiled from source using a fork of OpenEmbedded. Pyro is now retired.

The point is, Dunfell, Buster and Pyro are different distributions, and the same principle will apply, that an app compiled for, say, Pyro, might not work in Buster or Dunfell. However, Easy Containers fixes that.

When this webpage was originally written, in 2019, Buster was the current release, so the discussion below, and snapshots, are for Buster...

If you are running Buster, and click on the "sfsget" icon, this is the window:

img2

...you can see various SFS files, that can be downloaded, and you can choose to run them in a container or on the main desktop.

See the other path "easyos/oe/pyro". That has SFS files for Pyro. If you click that radiobutton:

img3

...take "pingus" for example. That is a game, compiled to run on Easy Pyro. If you were to download and install it, it can only be run in a container, in a layered filesystem with easy_1.2.2_amd64.sfs on the bottom. So you are really running the complete Pyro distro, but just the one app in it.

However, if you select "easy_1.2.2_amd64.sfs", as shown in the above snapshot, and click the "Download" button. it will install as a complete Easy Pyro desktop. In other words, after installing, this is what you would see on the desktop:

img4

...yes, you can run either Buster or Pyro as complete desktops in a container. If you click on "pyro", you get the familiar desktop of that series;

img6

A detail note: If you had previously installed "Pingus", then easy_1.2.2_amd64.sfs would already have been downloaded, so the above SFSget window would show "Install" in the button, instead of "Download". You can then proceed to install Easy Pyro as a containerised desktop.

Flipping and killing containers

Click on "pyro" icon will launch the Easy Pyro containerized desktop. ALT-F6 will flip you back to the main desktop. On the main desktop, click either the "pyro" icon or the entry in the tray to flip back into the Pyro container.

But how to kill a container? If running a single app in a container, such as Pingus, closing the app will also kill the container.

There is another way to kill a container, and this method is required if you want to kill the Pyro container. On the main desktop, right-click on the tray entry, and choose "Kill":

img8

Compile source code in a container

Compiling source packages in a container is convenient as it does not clutter up the main desktop. Sometimes also, a compiled and installed package may make the main desktop misbehave.

EasyOS 7.x has a pre-created "devx" container, especially configured for compiling. The "devx" icon can be seen in the photo at top of this page.

There is now a webpage tutorial for "devx":

https://easyos.org/dev/how-to-compile-source-code.html

An important difference with the "devx" container is that whatever partitions are mounted before starting the container, the working-partition excluded, will be bind-mounted inside the container.

Addendum

There are security advantages of running an app in a container. However, EasyOS has another mechanism that offers excellent security; run each app as its own user.

Chromium defaults to run as user "chromium" on the main desktop. This provides isolation, especially from other apps running as their own user.

So, Chromium on the main desktop has very good security, and of course it has its own sandbox.

Note though, when Chromium is run in a container, it will still run as user "chromium" inside the container, and will still have its own sandbox. So, there are multiple levels of security.



Tags: user