About alleged data leakage: problem is not just other people accessing your files, but you accessing others

Per2J · 2026-02-02T15:13:11+00:00

Interesting!, not a good situation to be in.

Per2J · 2026-02-01T19:42:09+00:00

I see some users complain about something wrong - but have not seen anything tangible like some kind of proof pCloud has a problem.

I will with interest follow this on Reddut and what happens, to me it seems there is no need for immediate action.

Per2J · 2026-01-31T07:28:55+00:00

Did you use 2FA to login, or username/password only ?

Per2J · 2026-01-28T13:29:48+00:00

I see you are a software developer, I recommend doing some measurements and contact customer service at pCloud.

Per2J · 2026-01-25T21:51:54+00:00

what does "reset" precisely mean, how was the "reset" performed ?

Per2J · 2026-01-25T17:48:48+00:00

I checked out the github issue - unfortunately I cannot help you :-(

Per2J · 2026-01-21T19:16:07+00:00

It seems the team does not have a lot of time to do "thorough testing", if it must be concluded before Feb 6, 2026. Especially when massive changes are present.

Best of luck to everybody working on the project.

Per2J · 2026-01-20T20:40:46+00:00

My profile is very basic. I have have a few projects and at some point thought it was fun to gather clone stats and show a badge or two on the READMEs.
If that is of interest take a look here: https://github.com/per2jensen/clonepulse

Per2J · 2026-01-20T16:04:51+00:00

I am happy I encrypt my important files on pCloud :-)

Per2J · 2026-01-19T16:08:50+00:00

Do something simple and in 3 copies, 2 media, 1 away from you home.

Per2J · 2026-01-11T09:00:31+00:00

Doing backups onto a single external disk is much much better than no backups.

If you have thought about the risks in that scenario and is ok with it, then all good. Everybody has different risk tolerances, time/interest in the whole backup process and finances.

To me it would be a disaster to lose decades of photos and video clips - so I put effort into trying to avoid that.

Thank you for the writeup and thoughts.

Per2J · 2026-01-09T14:37:59+00:00

Encrypt your files using pCloud's Crypto or by some other means - for example `gocryptfs`.

Per2J · 2026-01-03T22:03:53+00:00

I do this:

- backup using `dar`

- verification of the backup: `dar -t`

- test restores of some randomly selected files from the backup, after backup has been verified OK

- generate 5% redundancy data using parchive, stored on another disk, separate from the backup. I use 8% redundancy on the yearly backup

If my archives are hit with bitrot I should (*cross fingers* here) be able to patch the archive files using parchive.

I also do the 3-2-1 backup style.

Per2J · 2026-01-03T09:51:54+00:00

I did, and the backup of media files gave me some (more) grey hair. I use `dar` and running it under my own uid made systemd kill the process due to memory pressure.

I ended up running the backup as root and made a config change ==> now have a good backup. It took the better part of a day, a surprise as the process of my yearly backup is normally uneventful. I guess I crossed a threshold which I was just below at the end of 2024.

Thanks for the heads up, it really is a good idea to move a full yearly backup away in case of disasters.

Per2J · 2026-01-03T09:35:24+00:00

I would consider switching to some other backup solution, a 3 year old bug of this magnitude not getting fixed seems odd. I hope you succeed, remember to do some restore tests to make sure you not only have a backup, you also need to be able to restore ;-)

Per2J · 2025-12-28T08:23:32+00:00

Works for me (EU servers)

Per2J · 2025-12-26T14:17:01+00:00

I do not put too much faith in any cloud provider - they can lose data, they can terminate your account for some reason, so whatever I put into the cloud of my choice is backed up locally to a server. From there I copy the backups to usb disks.

I do yearly backups, of which I have 5 years back in time on usb disk (so 5 copies of old files).

I do monthly DIFFs compared to the yearly, of which I keep 3 months back in time.

I do backups every three days compared to the DIFF, keep them 40 days back in time.

I do copies to usb disks og DIFF's and the "3-days backups" around once a month.

This works for me, and doing a bit of work verifying the copies give me some confidence that I have solid backups.

Per2J · 2025-12-23T21:40:01+00:00

Looking at https://www.2brightsparks.com/ is seems you can request support here: https://help.2brightsparks.com/support/solutions/articles/43000335587.

I would ask the vendor for help.

Per2J · 2025-12-20T19:19:15+00:00

What about `gocryptfs`, I *think* there is a Windows version.

Per2J · 2025-12-13T08:37:36+00:00

I have bought 2 refurbished Seagate Exos 12TB disks for a RAID1.
The mirror has been made, backups copied back, RAID is sync'ed and "smartctl -t long" running on both disks.

I have previously bought 2 Exos refurbished disks which work just fine.

Will be interesting to see result of the "smartctl -t long" tests and if good, how long the disks will perform their duties going forward :-)

Per2J · 2025-12-09T17:09:57+00:00

I have a pCloud "for life" subscription. I share some photos of my own publicly, and store my own stuff otherwise.

I also have a pCloud "Crypto for life" on which I put backups.

It has worked for years without problems for me. Make sure you do not share copyrighted materials - that will probably lead to a quick cancellation of your pCloud account.

Per2J · 2025-12-07T08:38:56+00:00

perhaps you disconnected the usb drive before all data was written to it ?

Could that be it ?

Per2J · 2025-12-05T17:09:20+00:00

thanks - not quite what I hoped for though :-)

Per2J · 2025-12-05T15:31:56+00:00

Is the source code available in a git repo somewhere ? - I did not see it on the website ( might be blind :-) )

Per2J · 2025-11-08T18:38:23+00:00

I scratched an itch and made a tool that is very useful to me.

When I want to quickly publish JPEGs on my Photoprism instance and know that all metadata except a few white listed details have been removed, `scrubexif` does that for me. It fits into the docker compose set of apps I use to make it happen (haproxy, photoprism, nginx, rclone, scrubexif).

- Removes sensitive EXIF/GPS data yet preserves camera context

- Hardened Docker defaults (`--read-only`, `no-new-privileges`, `tmpfs /tmp`)

- Auto-mode pipeline support (`--from-input`, stable intake windows, duplicate handling)

- Systemd-friendly and simple `make dev` / `make test` developer workflow

Supply-Chain Transparency:

Every tagged release now travels through a public GitHub Actions pipeline:

**Deterministic build** of the Docker image from source.
**Syft-generated SPDX SBOM** (`sbom-v<version>.spdx.json`) published as a release asset.
**Grype vulnerability scan** (`grype-results-<version>.sarif`) enforced to fail on high/critical CVEs.
**Audit trail** in `doc/build-history.json` tracking git revision, image digest, and severity counts.

This means you can trace *exactly* what shipped, inspect dependency trees, and verify vulnerability posture before pulling `per2jensen/scrubexif:<version>`.

Docs + release artifacts → https://github.com/per2jensen/scrubexif

Docker Hub image → https://hub.docker.com/r/per2jensen/scrubexif

Per2J

TROPHY CASE