Default user (/home) shares and out-of-the-box collaboration

Did you talk about defaults for the new sharing feature already?

Looking at the current GUI mock-up, it seems it could still be much easier for all of the intended audience to have shares and groups readily configurable, allowing all freedombox users to easily collaborate on files by default. (Edit: See simpler settings mock-up in this post.)

So it may be good to have some sane safe defaults, that allow the users to collaborate out of the box, without requiring to set up all the above and custom groups.

And this is related to why my perspective is so positive for group owned directories, with a (finally also automatic) compliant umask 002 for the users with a user-private-group in debian (

What I have in mind is a default something like this:

  • Provide user authenticated shares over samba, when this can be considered save (maybe only for local nets?)
  • Make the /home directory browsable
  • Let /home also contain the user data of the defined groups, as for the default /home/group/users, /home/group/admins etc.
  • Let the users and group directories contain set-group-id sub-directories that implement inherent collaboration features (thanks to the user’s primary UPG and a 0002 umask).
    ( Example along the lines, but slightly improved from the Debian Wiki: )
[error: /home/<user-name>/public_write (not needed, use groupdir "users" instead) ]


This would allow the collaboration features to be discoverable and usable simply by browsing the filesystem, and without needing any setup by the user beyond opening the Freedombox network share. (And the network itself is usually also browseable with most operating systems.)


Interesting idea.

Many single board computers have very limited storage on the root device (SD card) and an have attached disks that are much larger and faster (USB disks). The proposal should account for this.

1 Like

Didn’t think the storage location would need to be related to the filesystem directory layout.

If the SDCard is really to be kept as (readwrite) system drive, which isn’t a good advise due to its limited reliability I think, it may be enough to move /home and mount or symlink it from the other drive.

A preferable alternative may be an option to move the entire root filesystem, but keep a backup copy on SDCard in case the board can’t boot from the external storage (not possible/detached/broken).

One technical advantage I see over the current Freedombox/share/{group,home,public} implementation is that it only requires a single default “share” configuration (one path) to serve and access all the user data in /home. The users get access to their individual data and all shared data, according to the filesystem permissions of the default directories, and any custom group-permission directories created below /home.

It might even work to share (samba), export (NFS), webserve (HTTPS/webdav) out a common / folder, by default, that can be directly visible without any authentication. It could list the /home directory, and any others, and ask for credentials when the user tries to enter the directory.

The options in the sharing UI may then only make other directories of the filesystem available and visible (over selectable protocols maybe) on the default main share/export/webserverer/etc.

By using default filesystem (sgid) group directories the entire second page of the configuration UI shown above woudn’t be necessary, anymore.

When creating shares is based on filesystem paths, the mounting of additional filesystems could be on a different UI page, while removable disks may be auto-mounted and be readily available for sharing.

Just for convenient customization, the share-UI may allow to list (possibly even browse) the subdirectories in a share, and to adjust the default permissions. It could also support to add further ACL based permissions if desired.

Here is some mock-up:

Freedombox Default Network Share

(+CC @vexch @njoseph)

Here is a comparison of both storage schemes. There seem to be advantages for both.

Please add further points if you know some.

Concerning the proposed simplified UI mock-up, I think it could support both storage schemes.

  • The /home share can always be created, by default.
  • Creating a default “portable share” could be an option when mounting a removable storage without support for unix permissions that does not have a share folder yet. (Creating empty directories for all possible groups.)
  • The sub-directory listing could work the same on both type of shares, but only allowing the adjustments that are possible.
  • For portable storage, the properties would only allow to enable/disable the predefined home-share / open / freedombox-users subdirectories.
ad-hoc name-based sub-dir storage fs-based group-dir storage
sharing space config corresponds to user/group setup -
works without separate configuration -
full permissions support No (only home,users,open)
one-to-one user collaboration out of the box -
works on storage w/o unix permissions (FAT) -
everything writable, if mounted locally - (for root yes)
allows consistent storage permissions, if mounted locally (e.g. backup / replica / server down / offline usage) -
features are portable between servers Yes (may require a tool to adjust uids/gids on server or disk, or to make a copy based on user/group-name based mapping
trivial to support in share UI - ✓ (should work even without directory listing/adjusting support )
Click here for a table template to add further points.
|    |ad-hoc name-based sub-dir storage | fs-based group directories |
| ------ | ------ | ------ |
|  |  |  |
ad-hoc name-based sub-dir storage fs-based group directories
data separable on external disk ✓ (FreedomBox/share/…) Yes, on filesystems with permissions (FreedomBox/home/…)

I’ll try to add some concluded overview points of mine:

  • A default /home share with user-authentication can work well for a very broad, even quite sophisticated range of use-cases, without requiring any configuration or maintenance by the user.

  • The basics of UPGs and auto-creating personal user’s sharing- and group-subdirectories (/etc/skel & addgroup?) could all be made to work in Debian generally, even without any visible sharing UI (basic configuration steps here).

  • Access by applications that don’t run as a user process would continue be realized through ACLs (not directly visible).

  • A sharing UI that simply lists of all sgid-directories and their permissions in a share (and in a group/ sub-directory), can readily visualize the specific access possibilities for the user. The listing could allow to ease (filesystem) permission customization, if this is ever needed at all with good directory skeletons?

  • The “final touch” to be fool-proof comes from "inotifywatch"es on the group dirs, to automatically fix permissions of falsely (client-forced) permissions of SFTP uploads and moved files.

  • Access permissions for shares that are stored on non-unix filesystems would (still) require considerable abstract configuration on the sharing protocol level. The complicated configuration could be reduced, though, by

    • keeping the current admins/homes/public/read-only selection.
    • or, using the same general user/group/others scheme (but using filesystem mount options to restrict local and remote access to user/group/other).

    In both cases, storing individual, user-specific data would still need the “homes” share setup, that maps the names of directories to user accounts and access permissions.

Nicely complementing initiatives:

  • A separate <mountpoint>/FreedomBox/ subdirectory on external/portable storage that can contain app specific data directories as well as all the user data under FreedomBox/home (on unix filesystems).

  • A central storage place for all the freedombox configuration under /home/freedombox/<absolute-path-in-rootfs>. It allows to nicely move or copy all configs to external/portable storage together with the user-data (e.g. <mountpoint>/FreedomBox/home/freedombox/etc/plinth/plinth.config).