Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EACCES Error relating to 7za when creating backup archive #66

Closed
c0f opened this issue Jan 23, 2024 · 15 comments
Closed

EACCES Error relating to 7za when creating backup archive #66

c0f opened this issue Jan 23, 2024 · 15 comments
Assignees
Labels
bug Something isn't working

Comments

@c0f
Copy link

c0f commented Jan 23, 2024

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

@JackGruber
Copy link
Owner

  • 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

@c0f
Copy link
Author

c0f commented Jan 24, 2024

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.

@JackGruber JackGruber added the bug Something isn't working label Jan 25, 2024
@JackGruber
Copy link
Owner

@personalizedrefrigerator Can you possibly help? Since you have customized something for the default installation on 7zip.

@personalizedrefrigerator
Copy link
Contributor

personalizedrefrigerator commented Jan 25, 2024

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.

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.

@laurent22
Copy link

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?

@JackGruber
Copy link
Owner

Maybe check in advance if 7 zip is executable and if not deactivate the compression and password options (do not show).

@c0f
Copy link
Author

c0f commented Jan 25, 2024

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'.

@personalizedrefrigerator
Copy link
Contributor

Pull request: laurent22/joplin#9780

@personalizedrefrigerator
Copy link
Contributor

personalizedrefrigerator commented Jan 25, 2024

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 bd49c66 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).

@personalizedrefrigerator
Copy link
Contributor

This should be fixed in version 2.14.11!

@c0f
Copy link
Author

c0f commented Jan 26, 2024

I've tested it in 2.14.11 and it works!

Thank you.

@c0f c0f closed this as completed Jan 26, 2024
@JGCarroll
Copy link

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.

@JGCarroll
Copy link

JGCarroll commented Jan 27, 2024

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.

@personalizedrefrigerator
Copy link
Contributor

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 laurent22/joplin@b51e16c, 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.

@JGCarroll
Copy link

JGCarroll commented Feb 2, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants