JackGruber
EACCES Error relating to 7za when creating backup archive
Hi, when I run a backup I get the following error:
createZipArchive: spawn /tmp/.mount_JoplinPwiy47/resources/build/7zip/7za EACCES
The backup creates source files in my backup destination under a folder called 'joplin_active_backup_job'. This folder contains all of my notes as individual files. I assume this is a temporary copy before the archive is created.
At the same time the backup also creates an empty folder called 'JoplinBackup' in my backup destination.
Nothing relating to backups is written to $HOME/.config/joplin-desktop/logs.txt.
The following error is shown in activeBackup.log:
[2024-01-23 17:38:29.143] [error] createZipArchive: spawn /tmp/.mount_JoplinPwiy47/resources/build/7zip/7za EACCES
There are no other errors in the activeBackup.log and the error above is the last entry in the log.
/tmp/.mount_JoplinPwiy47/resources/build contains the following files:
-rw-r--r-- 1 root root 1457384 Jan 18 22:05 7za
-rw-r--r-- 1 root root 3672 Jan 18 22:05 license.txt
If I go into a terminal and try to run 7za from this folder I get a 'Permission Denied' error. The same happens if I try to run 7za with sudo. I cannot make 7za executable as sudo. I assume this is normal behaviour and part of the AppImage sandboxing.
I have tried closing Joplin and deleting the entire /tmp/.mount_JoplinPwiy47. The folder is recreated when I next run Joplin but the EACCES error persists.
Changing the 'Temporary export path' to a folder within my user home folder does not remove the error.
I have the following backup configuration options:
- Backup path: An empty directory within my home directory
- Keep x backups: 100
- Backup interval in hours: 24
- Only on change: Ticked
- Password protected backups: Unticked
- Password: Not set
- Loglevel: Verbose
- Create archive: Yes, one archive
- Compression level: Normal
- Temporary export path: An empty directory within my home directory (not the same path as Backup path)
- Backup plugins: Unticked
- Export format: MD Frontmatter
- Single JEX: Unticked
- Command on Backup finish: Blank
I am running Joplin desktop version 2.14.10 on Kubuntu 23.10. Simple Backup is version 1.3.6.
Joplin 2.14.10 (prod, linux) Sync Version: 3 Profile Version: 45 Keychain Supported: No Revision: 3ed6ad5 Simple Backup: 1.3.6
- Is this with the Buildin Backup Plugin oder with a seperated installed ?
- I think it's about a snap installation?
- Yes, the backup cannot continue because it has no access to 7za and is terminated
Hi I'm using the AppImage version of Joplin desktop from the Joplin web site.
I haven't installed any plugins myself, I'm using the included 'Backup' plugin that came with the AppImage.
@personalizedrefrigerator Can you possibly help? Since you have customized something for the default installation on 7zip.
Thank you for reporting this! I can reproduce this on Ubuntu 23.10.
Because of code signing issues on MacOS, we bundle 7zip with Joplin (rather than with the .jpl file for Simple Backup).
Semi-related (but different) issues on other projects.
- https://github.com/AppImage/AppImageKit/issues/1021
- https://github.com/marktext/marktext/issues/1164#issuecomment-518206810
My guess would have been that /tmp is mounted as noexec. However, on my system, I'm able to create a subdirectory of /tmp, put an executable in it, and execute it (so this probably isn't a noexec issue).
One possible solution could be to copy 7zip/7za to a different location before executing it on Linux. For example, to a subdirectory of ~/.config/joplin-desktop/cache.
Also I wonder how that will work once the app is bundled with Snap?
Perhaps as a fallback we could simply not compress the backup if 7-zip fails?
Maybe check in advance if 7 zip is executable and if not deactivate the compression and password options (do not show).
I liked the idea of putting the 7za executable in ~/.config/joplin-desktop/cache or it could be temporarily put into the 'Temporary export path'.
Pull request: https://github.com/laurent22/joplin/pull/9780
I'm using the included 'Backup' plugin that came with the AppImage.
This should be Simple Backup v1.3.5 -- Joplin's default plugin build script points to commit bd49c665bf60c1e0dd9b9862b2ba69cad3d4c9ae which is version 1.3.5. (We didn't update to 1.3.6 because the only listed change was related to plugin metadata (icons & screenshots) ).
As such, if the about screen shows version 1.3.6, there's probably a bug somewhere. (For me, it shows version 1.3.5, but I'm testing with a self-built AppImage).
Also I wonder how that will work once the app is bundled with Snap?
I don't expect the 7za binary to be too problematic. I can either wrap around it, bundle the Ubuntu version, or patch the plugin itself since it's now essentially part of the core app; assuming it's even a problem, it might happen to work just fine.
I've tried to test it now to confirm but unfortunately the plugin when loaded from from the Joplin executable (I.E 2.14.x) doesn't initialise properly. The plugin is shown as installed and as built-in, but the config for the plugin in the options menu doesn't load at all.
As far as 2.13.x goes installing it manually, the functionality works just fine, so assuming I can figure out why the UI won't load, I'd expect the 2.14.x version to work fine too.
I've found the problem; the snap turns off Asar bundling because I copied the idea from the Flatpak. I believe the idea in the flatpak is that by removing the bundling, the Flatpak update mechanism can more efficiently target specific files that have changed between releases. Snap updates don't work the same way and update (usually) via the delta's between two squashfs files, so for me it's trivial to just turn the asar bundling back on to fix the built-in Simple Backup plugin.
Once that's done, the snap works exactly as expected.
Strictly speaking, this is somewhat a Simple Backup issue because the exact error was it was looking at the wrong path when Asar bundling is turned off, causing it to not identify the 7za file even though there is one, so other potential future bundled plugins could work fine with Asar bundling turned off.
On the other hand, it's a packaging issue, since all the official releases have Asar bundling turned on.
Long story short, the snap looks good but the flatpak probably needs investigating separately for their Asar settings.
I've tried to test it now to confirm but unfortunately the plugin when loaded from from the Joplin executable (I.E 2.14.x) doesn't initialise properly. The plugin is shown as installed and as built-in, but the config for the plugin in the options menu doesn't load at all.
This might be fixed by https://github.com/laurent22/joplin/commit/b51e16c255821154bc00817df74177149160a03f, which removes duplicated logic for finding the location of the build/ directory at runtime. The original code for doing this, present in ElectronAppWrapper.ts, might work even if Asar bundling is turned off.
It's certainly helpful for the flatpak. When I've evaluated it in the context of the snap, the only benefit is making it easier for people to see the shipped source code and perhaps (untested) some improvement in file access since every file is already archived? The main downside is very subtle breaking of API versus the official builds.
https://www.electronjs.org/docs/latest/tutorial/asar-archives#limitations-of-the-node-api
On balance, I don't think the behaviour breakages, rare as they may be, are worth the few people who might peek at the source code on the file system rather than via GitHub, especially given the build output is already processed by Typescript and is essentially not the real source anymore. Again, the Flatpak might disagree as their bandwidth usage on downloads will likely go significantly up, but ultimately that's Flathubs problem and I personally don't think it's worth shipping unnecessary behaviour changes on top of those that already make us weird by being sandboxed too.