genbushi

In the Enpass password generator, separator options, please allow random digit as an option. Based on this scheme article Thanks for all you do.

@Tamascha Not an Enpass representative in any way, just curious. What errors if any are being seen or encountered? This is odd, are there any errors? I also have MBP MacOS Monterey 12.x and have done several exports out of 1Password7 and imports to Enpass without issue. I do a lot of testing on Mac and Linux. As long as you have your credentials in 1Password7 (version 7 and not version 8), you should be able to export from 1Password7 in either the `.1pif` format, or even standard `.csv`, by selecting the vault to export and then `File > Export > All Items`.

Testing 6.8.0 beta... Initial reaction is I'm a bit disappointed the Mac version is still not Universal for native M1 support, I really feel this is a major oversight at this stage. The QT toolkit has had this support for awhile now. While new features and enhancements are appreciated, thank you, getting the Mac version on at least a Universal build should be a main emphasis. You're in a unique position with a great product that's "local by default" compared to the major alternatives, but not getting the Mac version Universal is a huge miss imo.

Ah, I think I understand. Are you syncing the vault to Google Drive via the builtin Enpass capability to sync to Google Drive? I don't believe this is an Enpass issue. Google Drive makes connected app data hidden, https://developers.google.com/drive/api/v3/appdata , "This folder is only accessible by your application and its contents are hidden from the user and from other Drive apps", I just setup a test vault and yeah nothing. So this would not likely work with Google Drive the way you'd like to share it, but its Google that has this behavior not Enpass. That being said, the vault can be placed on Google Drive manually by either uploading a backup from Enpass, or changing the default Enpass vault location to a folder that's synced on your computer with Google Drive, those then could be shared via regular sharing methods.

You should be able to share the file and send your fiancee a link as in any other file share, unless I misunderstand the scenario. That being said, since this will be a "shared" file and vault with another individual, I'd recommend creating a separate Enpass vault with only those credentials you want to share with your fiancee. That way any other credentials are kept in your personal vault and not being shared. Additionally, there's also the ability to use the wifi sync - that may or may not be applicable. I don't know your life Enjoy.

This will work as intended with 2FA and Enpass. Please do enable 2FA in Dropbox. Once your Dropbox is set up with 2FA, when you first enable Dropbox sync within Enpass, you will need to authenticate to Dropbox and it will ask you to confirm to allow the Enpass app access to your Dropbox. Once that is done you're good to go. If Enpass ever is unlinked you'll need to then repeat the sync setup process.

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.

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:

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?

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.

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 it, but its a business and I respect their decision, that's their right after all. I did an install of Xubuntu 18.04, launching from command line produced this error: I then installed the missing library 'libxkbommon-x11.so.0' with command: sudo apt install libxkbcommon-x11-0 Afterwards I was able to open Enpass as expected via menu and command line

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.

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 more latest-release (which is why we all love it) - so may be some tweaks needed.

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.

Are you getting a specific error? If you run it from the command line via "enpass" command what errors or output is generated?

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

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: After clicking "open xdg-open" or "Redirect" that I was presented with a "KIO mimetype error, no application associated with enpassauth". As mentioned however, on this most recent installation everything is fine though. My guess is, looking at the file on a working install: $ grep MimeType /usr/share/applications/enpass.desktop MimeType=x-scheme-handler/enpassauth;x-scheme-handler/enpasscard;x-scheme-handler/enpassstart;x-scheme-handler/enpass;x-scheme-handler/cloudkit-xxxxxxxx.in.sinew.walletx;application/enpasscard; that on the install where I was having "KIO mimetype" errors it was likely missing this info in file "/usr/share/applications/enpass.desktop": x-scheme-handler/enpassauth

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.

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 resource and enter those details - then it will do exactly that. The only explanation really is that what @Ivarson mentioned that possibly your /home partition was not fully wiped and picked up that information, or you possibly did a database restore on configuration?