What can, inadvertently, trigger a remote wipe?

[mccurly]

Hi.

Yesterday, for the second time, in a month, remote wipe was triggered, from an Arch Linux desktop client, without any intervention, whatsoever, from the nextcloud server administrator, (myself), or the desktop going astray, in any form.

I am aware that Arch Linux distro, is under an unidentified, severe, and widespread DDoS attack for some weeks now, and, not only that, it was plagued with malware inside their AUR infrastructure.

Nevertheless, I want to be able to contribute to narrowing down the source of this remote wipe unwanted behavior.

Can anyone suggest, please, any actions to get nearer to the source of this?

Thank you.

[vawaver]

What you’re mentioning about Arch DDoS or AUR malware doesn’t really make sense in this context.
I’m running 3× Arch-based systems (CachyOS) with Nextcloud desktop client from repository and never had such an issue.

The important part is not what distro you’re on, but:

• what version of Nextcloud server you run,

• what version of the desktop client you use,

• and whether there’s any policy configured on the server that could trigger a remote wipe.

Without this information, it’s impossible to narrow down the problem. I’d recommend starting there, instead of assuming it’s related to Arch infrastructure.

[jtr]

@mccurly

Nevertheless, I want to be able to contribute to narrowing down the source of this remote wipe unwanted behavior.

Can anyone suggest, please, any actions to get nearer to the source of this?

Both client and server-side have logging.

Also all the remote wipe related API URLs (including for configuring it) all have wipe in them somewhere so grep your web server and/or reverse proxy logs for that string (including well before the wiping actually occurs on the client device).

[mccurly]

Hello.

Thank you for your answers and even more, your questions.

I consider them very important.

I agree that pointing somewhat to the distro is indeed speculative. And maybe unrelated.

Yet I remember, that is from memory indeed, I hadn’t turned on the desktop for a while. Some weeks (?). I’ll get the proper information later on if I can. That is the actual dates of the previous logins.

I noticed, nevertheless, that when issuing the update commands that, not only it didn’t actually update all the packages that were previously installed by yay package manager, but that it took quite a while to finish that incomplete update.

The system, the desktop, that is, actually became unresponsive, several times during that incomplete update.

And yes this is still speculative, of course.

Also, and I am almost certain of this that I am stating right now, the remote wipe trigger (I’ll call it that way), happened, more or less, again from memory, during the time the system was having its updates, and having its hiccups, hangings, whatnot.

About your specific questions, I’ll be able to answer them soon, when sitting at a desk with an easier interface to gather the important information you were pointing at.

Yet:

0.1. The server, although, is an all-in-one NEXTCLOUD docker instance, deployed (migrated) to a proxmox vm, by myself, from a previous docker infrastructure running inside an Arch Linux, desktop+server, running at the same Intel NUC hardware that the proxmox server is running on presently.

0.2. The nextcloud desktop version? (… Later on…)

0.3. I am positive that I didn’t specify any policies about remote wiping any of the clients that currently connect to the server. Not ever. I was even surprised (the first time it happened) a while ago, that is, some weeks ago, on an Arch Linux laptop client, as well… Either those wiping policies were deployed by default, or, if I did actually change any of those rules, I must apologize for taking your time.

About this latest paragraph, if that would be the case, of myself having misconfigured the server to that devastating extent, I would suggest, if I may, that a more explicit warning would show up everytime that policy or rule would be engaged.

That is, if I had inadvertently configured such a drastic measure, I must say, I did not realize I was doing it.

Which brings me, for now, to my last thought:

Which is the default policy about this procedure?

Can you @vawaver please answer?

Thank you.

See you soon.

[mccurly]

Hello.

Thank you for your suggestions.

Will do that indeed.

And post back.

Thank you for your kind attention.

See you soon!

[vawaver]

Remote wipe is never enabled by default in Nextcloud. It has to be explicitly configured on the server by the administrator. If you didn’t set such a policy, then it won’t trigger automatically.

What you describe (triggering during updates, system freezing etc.) looks more like a local issue with the desktop client or even the underlying system, not a server-side policy.

For context, I’ve been running Nextcloud AIO under Proxmox for almost 3 years now.
You can also find several of my posts here on the forum where I describe my setup and share results based on my own experience.

From my own usage: I only apply remote wipe in very rare cases, and always intentionally.
For automatic file deletion after a chosen number of days, I rely on tags and retention rules. Also worth noting: I always use the desktop client version from the official repositories.

To move forward you should provide:

• exact Nextcloud server version,
• whether you are running the latest Nextcloud AIO release or an outdated one,
• exact desktop client version,
• and ideally enable debug logging on the desktop client to capture what happens when the “wipe” is triggered.

[mccurly]

@vawaver

Remote wipe is never enabled by default in Nextcloud. It has to be explicitly configured on the server by the administrator. If you didn’t set such a policy, then it won’t trigger automatically.

Ok I get that.

Questions:

Is remote wipe only activated on the server (side)? (If so) Could you please point me to where does that setting lie?

@vawaver

What you describe (triggering during updates, system freezing etc.) looks more like a local issue with the desktop client or even the underlying system, not a server-side policy.

Agree. It should be like so. One question: What would happen if the underlying directory would be rm’ed on the client? I am guessing that the remote flag would also be triggered. Correct? But maybe not quite. As you can see I do not know how Remote Wipe actually works.

@vawaver

For context, I’ve been running Nextcloud AIO under Proxmox for almost 3 years now.
You can also find several of my posts here on the forum where I describe my setup and share results based on my own experience.

Thank you for your assistance. I’ll check your other contributions as well. I believe in you when you allude to your 3 years of successful usage of a similar system like mine. Please note that I am not questioning the operation of any such components or the whole system for that matter. I am trying to pinpoint what could be the cause / origin of my unwanted and undesired events. Which happened twice in a month’s period and in two different computers. Like you, I am betting the origin might well be on my systems. And for the looks of it, this could be some malware file laying inside the ailing account, where this occurred both of the times.

@vawaver

From my own usage: I only apply remote wipe in very rare cases, and always intentionally.
For automatic file deletion after a chosen number of days, I rely on tags and retention rules. Also worth noting: I always use the desktop client version from the official repositories.

I think I am using the official one…

Issuing pikaur nextcloud I get (among other things):

@vawaver

To move forward you should provide:

• exact Nextcloud server version,

@vawaver

• whether you are running the latest Nextcloud AIO release or an outdated one,

(Again) I think, the latest one:

@vawaver

• exact desktop client version,

@vawaver

• and ideally enable debug logging on the desktop client to capture what happens when the “wipe” is triggered.

How?

I have some logs. Although I do not know if they are debugging logs, strictly speaking. I am willing to divulge them. Could you please point me to how should I sanitize them to prevent PI or PII to be divulged?

(Note: PI = Personal Information; PII = Personal Identifiable Information)

Thank you, again, for your attention, and willingness!

[jtr]

@mccurly

What would happen if the underlying directory would be rm’ed on the client? I am guessing that the remote flag would also be triggered. Correct? But maybe not quite. As you can see I do not know how Remote Wipe actually works.

Before proceeding, let’s make sure we’re all talking about the same thing.

Remote wipe is a distinct feature meant to remove data on devices in enterprise settings from devices that have been stolen, etc.

Are you seeing a Remote Wipe notification? Or are you just using that phrase to describe some random data deletion that you’re experiencing?

To answer your question as quoted above: if you’re running a sync client (such as the Desktop client), then removing data on the client locally is essentially the same as removing it on the server.

[vawaver]

Good that you confirmed you’re on the latest AIO and desktop client.

About your question (“what if the underlying sync folder is rm’ed on the client?”):
That does not trigger any “remote wipe” flag. The desktop client treats it as local deletions and syncs those deletions to the server (i.e., files get removed on the server side accordingly). That’s standard sync behavior. If the client was running while the folder was removed or the system hiccupped during updates, you’ll see a wave of local deletes being pushed upstream.

Where the real “Remote wipe” lives:
It’s a per-device action in Nextcloud, not an automatic policy. Check Settings → Security → Devices & sessions in the web UI. Each device/token has an action menu where you can revoke the token and trigger a remote wipe. If you never used that on the affected device, you weren’t hit by remote wipe.

How to verify what happened (do it on your side):

• In the desktop client open the desktop window (Settings → General) and use Create Debug Archive. It exports a ZIP with multiple logs (e.g., nextcloud.log.*, permanent_delete.log.*).
• On the server, inspect nextcloud.log.
• Compare timestamps around the incident. If the client logs show local deletions first and then server operations, it originated locally. If the server issued commands first, you’ll see that order as well.

Practical tips to avoid repeats:

• During OS/package updates or filesystem changes on the client, pause sync until the system is stable, then resume.
• If you suspect the client state is corrupted, revoke the device token in Devices & sessions and re-add the account.
• If you lost data, recover it from Deleted files in the Nextcloud web UI (server trashbin), provided trashbin/retention isn’t disabled.

---

[bb77]

Sorry folks, but it’s really not that complicated that it requires this much text and so many posts, especially not spiked with so many assumptions. The latter applies mostly to you, @mccurly.

‘Remote Wipe’ is a server-side feature that allows you to remotely wipe data on a device or app connected to your server (under ‘Personal Settings’ > ‘Security’ > ‘Devices & Sessions’). Depending on the device or app you trigger the action for, a remote wipe can range from doing basically nothing, to logging you out and/or deleting the local app data of that respective app, to logging you out and removing all files (desktop client). At least in theory. I’d say more often than not you’ll just get logged out rather than any data actually being wiped.

Important note: this can only be triggered manually (I’m not aware of any policies that allow it to be automated), and it only affects the one app or device you triggered the action for, and only the data managed by the respective app. It won’t wipe the entire device, and it won’t delete anything on the server.

A different story, and I think that’s what happened here, is this: If files or folders are deleted on a client that’s connected to the Nextcloud server via the desktop client, for whatever reason (user action, malware, etc.), those files will also be deleted (or moved to the recycle bin) on the server. And yes, that’s normal, because that’s what synchronization means. Synchronization = keeping things in sync, so if something gets deleted on one end (client), it gets deleted on the other end (server) too. That’s why backups are so important.

Ok, I guess this text also got a bit long in the end.

[mccurly]

@jtr

Before proceeding, let’s make sure we’re all talking about the same thing.

Remote wipe is a distinct feature meant to remove data on devices in enterprise settings from devices that have been stolen, etc.

Are you seeing a Remote Wipe notification? Or are you just using that phrase to describe some random data deletion that you’re experiencing?

To answer your question as quoted above: if you’re running a sync client (such as the Desktop client), then removing data on the client locally is essentially the same as removing it on the server.

Hi, @jtr, thank you for your interest, and to you and everyone else, I apologize to not answering sooner.

Well… direct answer (taken from my mobile phone web browser, approximately 2 hours after that remote wipe happened; the second screenshot was taken about twelve minutes after the first one):

@vawaver

Good that you confirmed you’re on the latest AIO and desktop client.

@vawaver Thank you. I appreciate your regard.

About the origin of that remote wipe I stand clear now. I understand that if the desktop client had removed the files (with that ‘plain’ rm command, it would have triggered the server wiping as well). I have one question about this though. What if the contents of the account’s folder were synced to any other ‘remote’ client as well. What would be the predictable outcome of that? (I believe it would wipe any other remote client’s account directories, correct?)

@vawaver

Where the real “Remote wipe” lives:
It’s a per-device action in Nextcloud, not an automatic policy. Check Settings → Security → Devices & sessions in the web UI.

Ok. Please take a look at this:

In turn, yet, I am skeptical about the details one would obtain from these files, that are present in the debug log that we were looking for:

If you look closer the date of the .sync_147ffbbbed8e.db sqlite file is very close to when these latest oddities happened. Before looking for ways to grasp or poke into its contents (if there might be a way to have that insight into it), I ask you for a more expert advice: could there be any accidents by opening this sqlite file/db?

@vawaver

Practical tips to avoid repeats:
(…)

Ok. Looks very sensible. I will follow these advices as well!

@bb77

(…)not spiked(…)

Hi, thank you for your wise words! I must admit I have trouble getting to the point.

Please do not get upset by my way of being. I know this is a community. And I can assure you I mean well.

So… please do not take my ‘testaments’ too hard… I mean them well and strive to keep to the point while giving as much information as needed. (moving on… )

Last quote:

@bb77

Synchronization = keeping things in sync, so if something gets deleted on one end (client), it gets deleted on the other end (server) too. That’s why backups are so important.

So this might be the answer to my above question: I am guessing that this is some sort of FIFO command queue because what matters is when the command is issued and secondly (from) where the command is issued. That is: one file would be deleted everywhere it would be present if the latest operation pertaining that file would be deletion operation. That is, from a timezone meridian. Correct?

Last question:

I don’t remember having issued any remote wiping. Not on the first time (which happened on the laptop), nor on the second time, which, apparently, was ‘deemed’ to happen since the ‘depicted’ 14th of july 14 de julho (accordingly to the screenshot image above).

So the mystery still remains…

Thank you for reading and helping!

[jtr]

Okay, yeah that is definitely the Remote Wipe feature so it’s being triggered somewhere. This has nothing to do with syncing empty folders from a corrupt system or anything like that. So something is going on here, since a wipe has to be manually triggered.

Ok. Please take a look at this:

The screenshot with the trash icon indicates the remote wipe has already been requested (but not yet completed).

The way to trigger a remote wipe is to select the 3-dot menu on a device/session (such as those ones above) and selecting Wipe device. Even then it’ll pop up a prompt that says Do you really want to wipe your data from this device?

The only other way (outside of the Web UI) to trigger a remote wipe I’m aware of is via the provisioning API (which would be something you might use if you had some custom account provisioning tools).

If neither of the above jog the memory of you or your admin about the origin of the Remote Wipe request, the only way to track down what’s going on is going to be to look at your server-side logs. I already gave some clues what to look for in just the web server logs: any transactions with wipe in the URL.

[mccurly]

@jtr

If neither of the above jog the memory of you or your admin about the origin of the Remote Wipe request, the only way to track down what’s going on is going to be to look at your server-side logs. I already gave some clues what to look for in just the web server logs: any transactions with wipe in the URL.

Hello, @jtr , thank you for your kind assistance.

As you can see, I have replied, again, with the promptness that I could. (I guess we all wanted that promptness, but oh well)…

After you pointed that strategy for searching the logs for the wipe transaction that indeed lead me there.

Since all of the infrastructure for both the All-in-One Nextcloud and the (needed) proxy-manager (Nginx-Proxy-Manager, npm, for that matter), is running from docker containers, I tried to gather the docker logs as soon as possible.

After that, after having read your latest answer (the one that I quote above), I gathered the last logs from npm (both the app and its db) and searched therein (as well as in the other nextcloud-aio containers), for that wipe’string’.

This was the result:

The result was ‘null’…

Also these are the longest the logs span… :

As you can see, maybe this will all be inconclusive. The fact is that the logs do not span that much time (with the exception of npm).

Any more suggestions?

Thank you for your time and attention.

Cheers!

[bb77]

@mccurly

Any more suggestions?

Until someone proves me wrong, I’d still say that a remote wipe can only be triggered by a user via the WebUI (or via API, as @JTR mentioned). Therefore, you probably won’t find anything related in the Docker logs. I’ll also explain how it most likely happened: you wanted to remove a device and accidentally clicked ‘Wipe’ instead of ‘Revoke’.

Where exactly this gets logged, or if it gets logged at all, I honestly don’t know. But again, since it’s an application-level action in the user context, it should either be in the nextcloud.log (stored in data/nextcloud.log inside the nextcloud_aio_nextcloud volume), or in the audit.log. The latter, however, you’d have to explicitly enable: https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/logging_configuration.html#admin-audit-log-optional

If it didn’t get logged to the nextcloud.log, and if you haven’t enabled the audit.log, I’m afraid you’ll probably never find out when that moment was that you can’t remember anymore.

[mccurly]

@bb77

(…) device and accidentally clicked ‘Wipe’ instead of ‘Revoke’.

Hi, I can settle with that.

There are times when I am in a point where I inadvertently do things I shouldn’t.

And ‘now’ the time comes (as well), where I have to stand and face that, as difficult as it may seem. For myself, of course, and for asking you for assistance where, in the end assistance should not be needed.

Therefore, if this was the case, I am sorry. Please, do disregard all this thread, and, please, do note that I stand ashamed if I could have, inadvertently triggered this ‘havoc’.

And, since it may well be a possibility, do forgive me for coming to you and having presented you this case…

Forgive me, please.

Thank you, for any of your time.

[bb77]

@mccurly

There are times when I am in a point where I inadvertently do things I shouldn’t.

Yeah, who doesn’t? I’d say most people, but few admit it.

@mccurly

Therefore, if this was the case, I am sorry. Please, do disregard all this thread, and, please, do note that I stand ashamed if I could have, inadvertently triggered this ‘havoc’.

There’s no need to apologise for asking a question or for following up on it.

@mccurly

Therefore, if this was the case, I am sorry. Please, do disregard all this thread, and, please, do note that I stand ashamed if I could have, inadvertently triggered this ‘havoc’.

And, since it may well be a possibility, do forgive me for coming to you and having presented you this case…

The younger generation (younger than me, no idea how old you are) would probably use the word “cringe” now, or maybe not, what do I know, I’m approaching 50

@mccurly

Forgive me, please.

Wouldn’t you have to do something terrible for that to be necessary?

@mccurly

Thank you, for any of your time.

You’re welcome.