Jump to content
Enpass Discussion Forum

genbushi

Members
  • Content Count

    13
  • Joined

  • Last visited

Community Reputation

7 Neutral

About genbushi

  • Rank
    Member
  1. I just wanted to chime in because the Enpass team is taking a lot of heat here with M1 support. The issue with native M1 support is due to the underlying QT toolset that doesn't yet support M1 arm processors, not with the Enpass team directly. This is out of the Enpass team's control and upstream from them. QT is the programming toolset that allows Enpass to run cross platform on all these various operating system platforms, but in this case QT is not yet fully running natively on the M1 arm64 cpus. Once QT is ready for M1 I have no doubt we'll see a native Enpass M1 version shortly after.
  2. That's interesting, usually it'll use maybe under 75mb or so without including the various shared libraries. Was this a 20.04 -> 20.10 upgrade, and have you tried re-installing Enpass? If you're able, when you start Enpass, check the memory usage: Get the process ID: ps -o pid,user,%mem,command ax | sort -b -k3 -r | grep enpass Then use the resulting process ID: sudo pmap <processID> | head -n2 Or if possible use the System Monitor app to grab the Enpass app's memory usage:
  3. Is this ZFS also? If it's standard `ext4` and encrypts/decrypts properly it should be fine, especially if `/home/%user/.config/enpass/Backups` is working as intended. Does the `/home/%user/.config/enpass/data` directory already exist? If not, make those directories and try again possibly?
  4. My guess it'll be a few or several months before many applications are natively ported over to the M1 ARM architecture, I'm sure Enpass themselves are actively working on this internally. That being said, hopefully Enpass will run under the rosetta emulation layer, but we shall see as the units start getting out next week. I'm curious myself, please report your findings with rosetta.
  5. Awesome, glad its working... I just was doing some tests, see the library @Dentonthebear mentioned I believe. Putting here for reference. I'm a huge Enpass fan - it has some updating it needs for Linux, but it's awesome because its a local only password manager by default and works great on mobiles/tablets... everywhere essentially. As Manjaro and Pop_OS have brought even more folks to linux desktops, I'm hopeful a little more effort will be put in to maintaining the Linux builds (fingers crossed). Being an open source advocate I do wish they'd allow more code audits or even open source i
  6. If you open a command line window, return the output generated by starting it from the command line with the command: /opt/enpass/Enpass By they way, based on the kernel version, this is Xubuntu 18.04 LTS and not 20.04? I'm just a user, but I'll try to spin up an Xubuntu instance and see if I can replicate, it seems there's a few XFCE based issues.
  7. Hmmmm... guessing it may be something with the XFCE Manjaro tray and the underlying QT. Manjaro XFCE may be on a slightly more recent version of XFCE? Using it on Manjaro KDE, Gnome and Cinnamon has worked as intended. Let's hope the Enpass devs are able to get some further testing and a new build out. I think with the latest round of major releases (Ubuntu 20.04, Manjaro 20.x, KDE Plasma 5.19, Gnome 3.36.x, XFCE 4.14.x) there's a few underlying issues with how QT is being handled in various desktop environments. Ubuntu/Xubuntu plays things very conservative, whereas Manjaro is a bit mor
  8. I have a similar installation, but no issues here. I'm currently running Manjaro KDE. App auto starts in tray made successfully. I do not have `Always run Assistant in docked mode` enabled. I'd be curious to hear if you're running the KDE Plasma desktop or possibly one of the other Manjaro desktop environments where the tray service may not register the QT tray icon properly, etc.
  9. Are you getting a specific error? If you run it from the command line via "enpass" command what errors or output is generated?
  10. It kind of sounds like the repository didn't get added fully or your list didn't update. - Check all steps from install are complete. https://www.enpass.io/support/kb/general/how-to-install-enpass-on-linux/ - Afterwards, do an `sudo apt-get clean` and `sudo apt-get update` - Did you see the `apt.enpass.io` repository scroll by when running `sudo apt-get update`? Do you see the repo file when entering the command `cat /etc/apt/sources.list.d/enpass.list` ? - Try installing Enpass again with `sudo apt-get install enpass`.
  11. of course, on the most recent installation, everything works mainly as intended, lol. Try to relate what I did see however: Environment: - On initial install, observed minor notification: Setting up enpass (6.4.1.643) ... Error in file "/usr/share/applications/org.kde.kdeconnect_open.desktop": "*/*" is an invalid MIME type ("*" is an unregistered media type) Processing triggers for mime-support (3.64ubuntu1) ... - Continue to configure app, and click to setup cloud sync, Dropbox for example. Get normal dialog for "xdg-open" which is normal:
  12. Apparently there's a mimetype issue when it's calling the xdg-open command to go back to enpass during this process. I'll try to grab more screenshots later today/tomorrow.
  13. Hi @avinator What method was used to wipe the HD before the fresh install? Unless you use a method like shred, DoD wipe, or similar utilities that write random passes of null data to the drive, data persists even though one is doing a "fresh install". I do lots of installs across different linux based systems and do use the Enpass cloud sync to a local, private network resource but haven't been able to reproduce the behavior. The only way I can somewhat replicate is on a new installation where I manually tell Enpass on the initial setup to restore an existing user database from my cloud r
×
×
  • Create New...