Unable to download some files using 1Password for Linux

FYI, I'm able to attach files once again using the nightly build, however (and I noticed this before switching to the nightly build) I'm still unable to download those same files.

When running 1Password via command line, here's the error that occurs whenever the download button is clicked:


ERROR 2024-06-27T21:36:53.771 tokio-runtime-worker(ThreadId(28)) [1P:ffi/op-core-node/src/lib.rs:503] Write(OpOpen(InvalidPath))
(node:590219) UnhandledPromiseRejectionWarning: Error: Write(OpOpen(InvalidPath))
(Use `1password --trace-warnings ...` to show where the warning was created)
(node:590219) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)


If it run it with --unhandled-rejections=strict, the error is the same.

@chamiltonccn,

Do you have a ~/Downloads folder (As a sub directory of your user folder)? E.g. Josh/Downloads

@Joshua_ag

Do you have a ~/Downloads folder (As a sub directory of your user folder)? E.g. Josh/Downloads

I do, but it's a symlink to an external hard drive, however that doesn't seem to matter because if I remove the symlink and create a ~/Downloads directory, I get the same result.

Thanks for the info @chamiltonccn, we've split out the topic since this is about downloading files from 1Password not uploading files to 1Password.

That's odd, it seems like that should work.

Do you have a ~/.config/user-dirs.dirs file and is there anything set for XDG_DOWNLOAD_DIR

And if there is something set for XDG_DOWNLOAD_DIR, is that directory your Downloads folder?

@Joshua_ag

Do you have a ~/.config/user-dirs.dirs file and is there anything set for XDG_DOWNLOAD_DIR

That was the problem! (Well, for downloading files, anyway)

I have no idea how it got this way, but here's what it was set to:


XDG_DOWNLOAD_DIR="$HOME/"


Keep in mind, my downloads folder has been configured in its current state (~/Downloads as a symlink) for about two years and no other programs seem to have any issues. Correcting it:


XDG_DOWNLOAD_DIR="$HOME/Downloads"


... fixed the issue. I'm sorry, I didn't even think to check that; thank you!

@chamiltonccn

That's great to hear! Glad we found the source of the issue.

Yeah I'm not sure why we decided to use that particular system to determine the downloads folder.

Anyway we are happy to help and these types of things happen. Glad it was a quick solution

@Joshua_ag

Yeah I'm not sure why we decided to use that particular system to determine the downloads folder.

Well, it's a fairly common thing across multiple Linux distros so I'd imagine that had something to do with it :-)

That being said (and for the potential benefit of future readers of this thread) the drive must have become unmounted at some point and then some time later xdg-user-dirs-update executed, and that's how ~/.config/user-dirs.dirs got broken. To test this, I intentionally unmounted the drive where my downloads folder lives, then executed xdg-user-dirs-update, and I received the following message upon execution:


/home/chamilton/Downloads was removed, reassigning DOWNLOAD to homedir


So mystery solved, thanks again for the assist!