Looks like the failing call is logged in a stack trace:
$ touch /tmp/example
$ sudo systemd-run --property SystemCallFilter='@system-service' --property SystemCallFilter='~@privileged' --property SystemCallFilter='~@resources' sed --in-place '#noop' /tmp/example
Running as unit: run-r107c83f7687f4b32a4a53ae456c42081.service
$ journalctl --identifier 'systemd-coredump' --since '1m ago'
Feb 09 12:53:00 main systemd-coredump[34681]: [🡕] Process 34673 (sed) of user 0 dumped core.
Module sed without build-id.
Stack trace of thread 34673:
#0 0x00007f34e8c6d11b fchown (libc.so.6 + 0xfc11b)
#1 0x0000000000407c98 closedown (sed + 0x7c98)
#2 0x00000000004087b8 read_pattern_space (sed + 0x87b8)
#3 0x000000000040a44b process_files (sed + 0xa44b)
#4 0x0000000000403a74 main (sed + 0x3a74)
#5 0x00007f34e8b98fce __libc_start_call_main (libc.so.6 + 0x27fce)
#6 0x00007f34e8b99089 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x28089)
#7 0x0000000000403b95 _start (sed + 0x3b95)
ELF object binary architecture: AMD x86-64
In this case it’s fchown so appending @chown sounds appropriate.
In the past I’ve used this technique as well to figure these out.