This class is public, adding virtual methods is BIC.
You have to make a V2 class that inherits from this one (with a KF6 TODO to merge them), or a completely separate class that's specific to privileged operations.

Remember to add @since 5.37 to the class.

s/the the/the/

Best class ever. Add a comment to explain what it does?
(not much, AFAICS....)

this calls for a switch()

opendir can return 0, in which case the next line will probably crash.

Overall, this whole method seriously lacks error handling in my opinion. Just checking for errno at the end isn't enough, e.g. in cases like this where multiple calls are being made.

And even otherwise, I'm unsure if ignoring the return value of chmod/chown/unlink/mkdir and *just* checking errno is enough or not. Does anyone else know?

should be FILEHELPER_H to match the filename

This isn't public API -> no @since.

I assume this enum is duplicated elsewhere (in whoever is serializing the arguments for FileHelper), right?
Can the duplication be avoided by sharing a private header? Otherwise this at least needs a comment like "keep in sync with..." in both places.

missing else or break here, no?
You're sending the valid fd, followed by -1.

The documentation for chown and others says:

Upon successful completion, these functions shall return 0. Otherwise, these functions shall return −1 and set errno to indicate the error.

It does NOT say, that errno isn't set when the function is successful. It seems to me that it would be perfectly valid for a libc implementation to do something like "try this, it fails (and sets errno), then try that, it worked, return 0".

For this reason I would feel much safer (especially in code run by root!) if the error handling was more classic, i.e. by checking return values.

this basically abuses a global variable for something that could just be a return value from this function.

should be unnecessary now, with the above suggested change

I hope we never have the opposite problem, where a libc function returns non-zero but "forgets" to set errno.
Now that you added return statements on success everywhere, maybe this line could say Q_ASSERT(errno != 0), or

reply.setError(errno ? errno : -1);

to make sure we never return success when an error happened.

Well, this proves exactly my earlier point: we should only test errno *when* a libc function fails.

If this code is still checking errno after success somewhere, then *that* it what should be fixed. And once it's fixed, there's no need to reset errno here.

(BTW strerror(11) is EAGAIN, "Resource temporarily unavailable", rather frequent for non-blocking sockets, which is probably what triggered the slave to wake up in the first place.)

So, where is this code checking for errno even after success? In the caller of this method? It's hard to review all these separate review requests because I never have a global overview or the ability to search across the whole codebase -- but at the same time, everything in a single merge request would kill this slow webbrowser... [QtWebEngine compiled in debug mode] :-)

BTW what happens if two instances of this helper (and two instances of kio_file) try to do this at the same time? Don't they need different socket paths, to avoid interferring with each other?

I suppose the PID of the kio_file process should be added to this path, which means passing it in the QVariantMap to exec(), right?

You send fd=-1 if opendir fails, but not if dirfd fails.
Is it even needed to send -1, if we're going to return an error reply anyway?
(disclaimer, I don't know sendFileDescriptor nor what the code on the calling side does)