Package Details: pcloud-drive 2.1.0-1

Git Clone URL: https://aur.archlinux.org/pcloud-drive.git (read-only, click to copy)
Package Base: pcloud-drive
Description: pCloud drive. Electron edition.
Upstream URL: https://www.pcloud.com/
Keywords: pcloud pcloud-drive
Licenses: LicenseRef-pcloud-drive
Replaces: pcloud, pcloud-git
Submitter: plague-doctor
Maintainer: zbe
Last Packager: zbe
Votes: 93
Popularity: 0.58
First Submitted: 2017-04-27 21:39 (UTC)
Last Updated: 2026-05-23 09:23 (UTC)

Dependencies (4)

Required by (0)

Sources (2)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 .. 23 Next › Last »

okichatan commented on 2025-09-17 04:52 (UTC)

Exactly same issues as @nasko. I tried the appimage direct from the pcloud site and it also isn't working.

nasko commented on 2025-09-16 15:28 (UTC)

I recently started experiencing a problem starting pCloud I now have aur/pcloud-drive 1.14.16-1, but the problem also manifested couple of days back, when I had 1.14.14 -

When I type pcloud in the terminal, I'm getting this output, and the app just won't start:

$ pcloud
Using TARGET_APPIMAGE /opt/pcloud/pcloud-drive.AppImage

My fastfetch output for system info: https://gist.github.com/nasko/09bd469fae4f8b54437e5f8f28b19019

PhiLinux commented on 2025-08-15 14:27 (UTC) (edited on 2025-08-15 14:30 (UTC) by PhiLinux)

@zbe

Oh that is indeed interesting! My cache still has a pcloud-drive.AppImage from May 14th... That was when we fiddled with the file name regarding the autostart issue. That was when the version number was dropped from the file name.

So this is most certainly the cause! Is there anything the package maintainer can do in this case? Seems like it might be a behavior that could be specific to yay and possible other AUR helpers aren't affected then.

Edit: Removing the old cached file did solve the problem for me as well. Hopefully we can figure out a clean solution for everybody.

rew1red commented on 2025-08-15 14:24 (UTC)

@zbe / @PhiLinux

That would make sense. I had this file versioned to prevent the problem, but changed that in https://github.com/wastrachan/pkgbuilds/commit/ab7d547fe65b5b3ea1cd936e66ab7366abb5a13a#diff-c981fdfbca16f2f727447a07effa90d44861647c18d35494ea2953b27edc97edL16-R17 to try to solve the "Duplicate Desktop Entry" problem reported a while back. If there were a way to tell the app not to create it's own desktop entry, this would be moot.

I'll see what else we can do there... a clean upgrade path is important.

zbe commented on 2025-08-15 14:20 (UTC)

I think the problem is older pcloud-drive.AppImage file in .cache/yay/pcloud-drive. I got mismatched sha256sum check as well. Just delete the file, PhiLinux.

PhiLinux commented on 2025-08-15 14:19 (UTC) (edited on 2025-08-15 14:22 (UTC) by PhiLinux)

The code matches for me too so that shouldn't be the reason.

The full link I get:

https://u.pcloud.link/publink/show?code=XZwGnW5ZrhkOy46busjMNcycWKNcbV5sKHb7

Edit: I also just checked the sha256sum of the download and it perfectly matches the one from your PKGBUILD...

3dcf61e542d9b762979d6de9d6c5f9540769e2e717a691e57365632bd1f6fda3

Weird...

rew1red commented on 2025-08-15 14:09 (UTC)

@PhiLinux--

That would be an alarming change. I'm hoping I just made a mistake, but the _api_code in the PKGBUILD seems correct.

You can help in fact, if you want to go to https://www.pcloud.com/release-notes/linux.html and copy the download link for the most recent version (1.14.14 (08/08/2025) | Download), the code parameter in that link should match the _api_code in the PKGBUILD (currently XZwGnW5ZrhkOy46busjMNcycWKNcbV5sKHb7 for me)

If it doesn't match anymore, it would imply that pCloud has started generating that link on the fly and I'll need to do some refactoring to try to get a unique download link at build time. I have concerns about this.

PhiLinux commented on 2025-08-15 13:59 (UTC)

Thanks for the update to 1.14.14, however, I'm getting an error with the validity check when trying to update via yay.

I've noticed that when I try to open the new source URL from the PKGBUILD in Firefox, I get this error message:

"This link was generated for another IP address. Try previous step again."

So maybe the URL in the PKGBUILD can't work for anybody else either?! The validity check failing might just be a consequence of the download not working in that case, I'm not entirely sure.

The output where yay fails:

==> Validating source files with sha256sums...
    LICENSE ... Passed
    pcloud-drive.AppImage ... FAILED
==> ERROR: One or more files did not pass the validity check!
 -> error downloading sources: /home/phil/.cache/yay/pcloud-drive 
     context: exit status 1 

Let me know if there's anything else I can do to help figure it out.

endor43 commented on 2025-06-03 12:29 (UTC) (edited on 2025-06-04 07:30 (UTC) by endor43)

suspend solution here: https://bbs.archlinux.org/viewtopic.php?id=305971

and for popup for now I just created a kwin rule to keep it in the back

endor43 commented on 2025-05-31 12:02 (UTC) (edited on 2025-06-01 07:55 (UTC) by endor43)

On a fresh install of Arch, after installing pCloud, every time I click on the pCloud tray icon in KDE Plasma, a window pops up that says:

remote control requested an application requested access to: input devices it's this bug here https://bugs.kde.org/show_bug.cgi?id=490666

more importantly pCloud is blocking suspend for me. it just freezes the whole machine have to sysrq reboot. When I killall pCloud before sleep there are no issues whatsoever. Any ideas how to fix?

@rew1red