Looking for an E2E cloud provider that works with NixOS

tl;dr: I am looking for a recommendation for an E2E cloud provider that plays nicely with NixOS and ideally I am looking for help to get filen.io’s appimage running under NixOS.

I, like many others it seems, am in the process of migrating over to NixOS. In my case I am migrating from Ubuntu.

One of the apps that I use is from https://filen.io/ which is an E2E cloud provider (an E2E version of dropbox).

Filen supports Linux through an AppImage which is downloadable from their website: Filen – Desktop Client but does not appear to work on NixOS.

I have read a number of posts and so far this is what I have tried:

  1. Confirmed the application runs under normal Ubuntu (it does).
  2. Installed appimage-run into NixOS.
  3. Executed “appimage-run filen_x86_64.AppImage”.

When I do this in a terminal, I get the following output:

	[nix-shell:~/Downloads]$ appimage-run filen_x86_64.AppImage 
	filen_x86_64.AppImage installed in /home/moose/.cache/appimage-run/e6f927753f55ffcd5f51dcd2f8a4df0233c018ed08251c7c42137104d1bc9e75
	/usr/lib/libc.so.6: version `GLIBC_2.38' not found (required by /nix/store/vdg3lkws53kzxpyfw2lhgpmr2qw63fjc-gvfs-1.50.6/lib/gio/modules/libgvfsdbus.so)
	Failed to load module: /nix/store/vdg3lkws53kzxpyfw2lhgpmr2qw63fjc-gvfs-1.50.6/lib/gio/modules/libgvfsdbus.so
	15:50:33.502 › APPIMAGE env is not defined, current application is not an AppImage
	15:50:33.505 › Initializing startup windows
	[44:1115/155033.510022:ERROR:gpu_memory_buffer_support_x11.cc(44)] dri3 extension not supported.

I am left scratching my head and would appreciate any suggestions to try and get the application running.

As a curiosity, I have also tried to run a few other E2E cloud services under NixOS. By and large I have had issues with all of them:

  • Mega via megasync nixpkgs or flatpak. App works but the status indicator in the taskbar does not display.
  • Tresorit: Explicitly states on their website that NixOS is not a supported distro (due to non-standard file structure).
  • Icedive: Similar results as filen.io specifically also an AppImage and returns an error “libc.so.6 version “GLIBC_2.38” not found”
  • Internxt: AppImage but does run via appimage-run. However much like mega.sync, the status indicator does no appear on the taskbar.

I am searching for any help wrt filen.io specifically or any suggestions for an E2E cloud provider that works under NixOS.

Thank you from a NixOSNewbie

So, an appimage bundles a whole bunch of precompiled libraries into a single executable, kind of like a .exe in windows land.

Appimages don’t need to bundle all their libraries, though (just like .exes), and often don’t for a variety of reasons.

This means that sometimes they’ll fall back to a host library, executing it with the glibc from the appimage. Older glibcs cannot execute all things compiled against newer glibcs, and you get this error.

I’m assuming the application bundles glibc and this isn’t because you’re using an ancient glibc with nix-ld somehow, at least. You’re up-to-date with NixOS stable, so 23.05, and haven’t confused things with user channels somehow, right?

If not, for all intents and purposes, this appimage simply does not support NixOS (nor presumably Fedora, Arch, or a variety of other distros). This is one of the weaknesses of appimages vs flatpaks.

It’s also kind of difficult to fix, but maybe possible if you roll up your sleeves and build a copy of that library against an older glibc and get the appimage to load that somehow. I don’t have instructions.

Looks like they do publish their source code (since they bundle it with glibc it probably has to be GPL anyway), so maybe it would be easier to write your own package, but it’s electron so eh: GitHub - FilenCloudDienste/filen-desktop: Desktop client for Filen.io

I don’t have recommendations for commercial cloud hosts, I usually self host. Seafile may be up your alley if you want to give that a shot.

@TLATER, thank you for your considered and detailed reply. Based on what you have noted I will do the following:

  • Investigate packaging the source myself, but acknowledging that as the app it is electron it may make the undertaking particularly challenging (given that I will concurrently be learning about packaging for NixOS in general). Still nothing like a real problem to encourage the learning process. :wink:
  • I will look at Seafile as an alternate E2E file storage option. Thank you for the suggestion.
  • Long term I am keen to migrate to a self-hosted file storage solution, but transferring my base OS to NixOS is my primary focus. Once I am happy with my base OS, a self-hosted E2E file-storage solution would be the next step (and of course it will also be specified in NixOS).

I don’t have any experience with filen.io specifically, but since I was just working out a similar architecture for my own use I figured I might share some details with you here.

I have opted to use juicefs as a simple distributed file system to store some of my files in the cloud in an S3 compatible bucket. The main reason for this choice is cost, S3 is dirt cheap and since juicefs natively supports file encryption using your own personal RSA private key on the client side, and even metadata backups are also encrypted, there is no information leaked to the cloud provider. I also like being in control of my own keys, ensuring nobody else has access.

I intend on putting together a simple juicefs module since one does not currently exist in nixpkgs, but I don’t have anything tangible to share just yet. That said it was incredibly simple to set up and probably took me only about 30 mins to get everything up and running.

Probably worth pointing out https://wasabi.com/ when people mention S3 as dirt cheap for private cloud stuff, given it’s dirt cheaper and doesn’t have egress fees.

1 Like

@nrdxp, Thank you for the pointers. I will look at juicefs. I am looking to set-up something similar to what you are describing. The S3 compatibility will be a nice added benefit.

As TLATER said, your app ends up loading the old libc shipped with the appimage, before it could load the newer libc. At a later point the same process loads gvfs built by Nix, which expects the newer libc and finds the old one. You need to figure out a way to force the process to load the nixpkgs’ libc first. Maybe you could try LD_PRELOAD=/nix/store/..../libc.so appimage-run ..., but I don’t know if appimage-run actually propagates it

1 Like

Looks like it depends on the appimage: Should AppImages respect LD_LIBRARY_PATH? · Issue #126 · AppImage/AppImageKit · GitHub

If it doesn’t for this one, you could ask upstream to make it do so.

Very clever suggestion, hope I recall it next time I have glibcs tangled up.