Cannot mount local repository on Linux Mint 19.1 using Flatpak

[goebbe]

Describe the bug Testing the Flatpak build of Vorta on Linux Mint 19.1 I discovered that mounting a local backup does not work as expected.

To Reproduce Steps to reproduce the behaviour:

1. Go to 'Archives'
2. Click on a local backup to select it.
3. Click on Mount
4. Results: a) A dialogue opens in order to choose a mount point. b) After selecting Vorta shows the mount point (correctly). c) However the mountpoint (the directory) is not visible, any more in the file browser. ls -All shows the following line for the mount point (here: ~/mountpoint ): d????????? ? ? ? ? ? mountpoint

Expected behaviour: After 3. I would have expected that Vorta asks me for the password. If no or no correct password is delivered, Vorta should not even try to mount the backup.

5. Click "umount" result: the mountpoint is visible again (in the file system)

6. Mounting the backup on the console works: borg mount ~/myborgbackup ~/mountpoint
   result: after the input of the passphrase the backup is mounted correctly

Perhaps this is related to #316 ? Even though no sshfs is required here. borg mount requires the input of the passphrase - but there is not dialog asking for the passphrase?

Desktop (please complete the following information):

• OS: Linux Mint 19.1 (based on Ubuntu 18.04)

Thank you very much for providing a flatpak built. Installing via Pip did not work for me. :-/

[Hofer-Julian]

Thanks for opening the issue.

I am confused, what you mean with Vorta should ask for the password. Vorta only asks for passwords when you add an existing repository or create a new one. Then it gets its passwords from the keyring

[goebbe]

Sorry, I will try to give a detailed explanation of what I have done.

When I created the local repository I did the following in Vorta: Tab: Repository
select: +Initialize New repository Repository URL: I selected a local folder in my home directory Password: I typed my password for the (local) repository
I did not change the default settings Then I started the backup

(It is not possible to create a repository with Vorta, without defining a password

When I mounted the local repository on the console: borg mount ~/myborgbackup ~/mountpoint then I have been asked for a passphrase of the repository: Enter passphrase for key /home/myuser/myborgbackup: Here I type the password of the repository result: the repository was mounted at ~/mountpoint

Please let me know if you need anything else.

[Hofer-Julian]

Okay, so the directory disappears in your explorer and with ls you get a bunch of questionmarks?

[goebbe]

O.k. here is a more detailed description of what is going on, when I select my local repository in the Archive-tab:

• Select repository
• click on mount
• now I am asked to select a mount point (file dialog)
• I select a mountpoint result:
• In Vorta Archive-Tab, in the line of the repository, at the column "Mount Point": my selected mount point appears
• In File Manager:
  • the choosen mountpoint(folder) dissapears
  • the mountpoint appears in the side pane (as mounted) Now - if I selct the mount point in the side pane I get the following Error message: "The folder contents could not be displayed. Sorry, could not display al the content of "mointpoint": Error opening directory '/home/myuser/mountpoint': Transport endpoint is not connected" The folder is not displayed.

When I type ls -All now, in the console, then I get the following output: d????????? ? ? ? ? ? mountpoint

unmounting the repository (from Vorta) brings everything back to normal.

The log of Vorta contains nothing special: 2019-07-12 08:56:44,280 - vorta.borg.borg_thread - DEBUG - Using VortaSecretStorageKeyring keyring to store passwords. 2019-07-12 08:56:44,281 - asyncio - DEBUG - Using selector: EpollSelector 2019-07-12 08:56:44,290 - root - DEBUG - Found 1 passwords matching repo URL. 2019-07-12 08:56:50,802 - vorta.borg.borg_thread - INFO - Running command /app/bin/borg mount --log-json /home/myuser/myborgbackup::goebbe-ThinkPad-W520-default-2019-07-12T08:43:16 /home/myuser/mountpoint 2019-07-12 09:09:55,260 - vorta.borg.borg_thread - DEBUG - Using VortaSecretStorageKeyring keyring to store passwords. 2019-07-12 09:09:55,260 - asyncio - DEBUG - Using selector: EpollSelector 2019-07-12 09:09:55,267 - root - DEBUG - Found 1 passwords matching repo URL. 2019-07-12 09:09:55,313 - vorta.borg.borg_thread - INFO - Running command /app/bin/borg umount --log-json /home/myuser/mountpoint

Additional information: My Password contains underscores "_" borg has already be installed on this computer before. On the console:

borg --show-version
borgbackup version 1.1.5

[goebbe]

I just checked, to be sure. It is not the underscore in the password, that causes the problem.

[Hofer-Julian]

Your local borg installation shouldn't matter, borg is packaged in the flatpak. But we can use your borg installation.

Could you please try to run

borg mount --log-json /home/myuser/myborgbackup::goebbe-ThinkPad-W520-default-2019-07-12T08:43:16 /home/myuser/mountpoint

in the console?

Nice documentation of your problem btw :)

[goebbe]

"Transport endpoint is not connected" points to FUSE, which seems to be used by borg for mounting: https://stackoverflow.com/questions/24966676/transport-endpoint-is-not-connected

[Hofer-Julian]

@goebbe is "Transport endpoint is not connected" the message you get when you execute the command I mentioned above?

[goebbe]

@Hofer-Julian yes, this is in my third post. The error message is shown, when I try to access the "mounted" mountpoint directory.

[goebbe]

I updated borg to 1.1.9, now.
Result: I cannot access my repository via borg mount from the console any more. My passphrase is not accepted! Two thing I will check, now:

1. Downgrade back to borg 1.1.5 to check if this issues is really caused by the update.
2. Check borg directly for existing issues

[goebbe]

Hmm - downgrading to 1.1.5 did not resolve the issue. I was not able to access the repository any more (from the console). So I removed the repository and created a new one. - Now everything works as expected from the console - with borg 1.1.5 and with borg 1.1.9. I really wonder what went wrong here. I even checked my memory (memtest) since I had some problems with memory in the past - but my RAM seems to be fine.

@Hofer-Julian is FUSE packed into the Flatpak build? I suspect this is the case, since borg mount requires FUSE. Have you been able to reproduce the original issue?

[Hofer-Julian]

FUSE is packed into the flatpak.

I kind of lost track here..

Are we still at the point that mounting with local borg works but with Vorta-flatpak does not work?

[goebbe]

Yes, the issue is still unresolved.

Looking through the issues in borg: FUSE seems to be a mess. :-)

Things that could/should be checked:

• borg mount requires exactly version 0.5.6 of nsgpack (no newer and not older version!!) see: https://github.com/borgbackup/borg/issues/4534
• default permissions of FUSE have to be set correctly see: https://github.com/borgbackup/borg/issues/3903

[ThomasWaldmann]

borg mount requires exactly version 0.5.6 of msgpack (no newer and not older version!!)

No, that's not the case.

We bundle 0.5.6 with borg 1.1.10 because that is the newest/best supported version.

See setup.py of 1.1.9 for the borg 1.1.x (pre 1.1.10) requirements: https://github.com/borgbackup/borg/blob/1.1.9/setup.py#L42

[Hofer-Julian]

Yes, the issue is still unresolved.

Looking through the issues in borg: FUSE seems to be a mess. :-)

Things that could/should be checked:

* borg mount requires exactly **version 0.5.6 of nsgpack**     (no newer and not older version!!)
  see: [borgbackup/borg#4534](https://github.com/borgbackup/borg/issues/4534)

* default permissions of FUSE have to be set correctly
  see: [borgbackup/borg#3903](https://github.com/borgbackup/borg/issues/3903)

Also I want to add that I tested mounting on multiple distributions (not incuding Linux Mint). I still try to figure out if the problem only occurs at your setup.

[goebbe]

@Hofer-Julian: Thanks for the reply. I understand that the issue is not reproducible for you. Is it worth to bother the Mint developers with this issue? Please let me know, if I could test something - or if you need additional information.

[Hofer-Julian]

Yes, let's repeat it again. Try to mount something. Then execute the exact same command visible in the log in the console but with borg instead of /app/bin/borg

[goebbe]

Sorry, perhaps I lost track. Here is the output of the console:

borg mount --log-json /home/goebbe/mybackup::goebbe-ThinkPad-W520-default-2019-07-12T11:20:46 /home/myuser/mountpoint
Enter passphrase for key /home/myuser/mountpoint: 

result: after the passphrase the mount worked without a problem no other output is given on the console

Sorry, if this is not helpful. I am not a developer.

[Hofer-Julian]

It is helpful, it means it is a flatpak problem.

[goebbe]

In order to add additional data points I did the following:

• I installed Vorta (via Flatpak) in a virtual machine (Quemu)
• OS: LMDE 3 (Linux Mint Debian Edition) which is based on (old stable) Debian "Strech" but contains the new GUI-Stack (Cinnamon + Linux Mint software + flatpak integration out of the box).
• Result: Mounting a local repository works fine!!
• Here, Vorta is the only package I installed via flatpak.

[Hofer-Julian]

Thank you!

That is what I planned to try next. Is it the exact same OS as you use?

[goebbe]

No - but I continued to test: Linux Mint 19.1 (Cinnamon - based on Ubuntu 18.04 LTS) <- issue Linux Mint Debian Edition 3 (Cinnamon - based on Debian "Stretch") in virtual machine <- no issue Linux Mint Xfce (Xfce - based on Ubuntu 18.04. LTS) in virtual machine <- issue Next step in my pipeline is to test Ubuntu 18.04. directly.

[goebbe]

Last test: Ubuntu 18.04.2 LTS (GUI: Gnome) in virtual machine <- no issue

It seems like the issue is specific to Linux Mint (based on Ubuntu 18.04). I will open an issue on the bug-tracker of Linux Mint.

[Hofer-Julian]

Thanks 👍

[goebbe]

This is the issue on Linux Mint: https://github.com/linuxmint/mintinstall/issues/254

[goebbe]

Sorry for closing and reopen. :-( Just for the record: Debian stable (GUI: Cinnamon, Buster) <- no issue

[goebbe]

The Issue is due to the default kernel, used in Linux Mint 19 (that is based on Ubuntu 18.04.0). Installing a newer kernel, e.g. one of the hwe-stack, the issue disappears.

4.15.0-54-generic # 58-Ubuntu x86_64 GNU/Linux <- default kernel - issue appears 4.18.0-25-generic # 26-18.04.1-Ubuntu x86_64 GNU/Linux <- no issues 5.0.0-20-generic # 21~18.04.1-Ubuntu x86_64 GNU/Linux <- no issues

Workaround: Install one of the newer kernels available in the hardware ennablement (HWE) stack of Ubuntu

This issue can be closed.