the workaround consist in temporarily turn off the syntax check with the parameter nsslapd-syntaxcheck under cn=config with a ldapmodify command.

Upstream ticket:
https://github.com/389ds/389-ds-base/issues/4383

Update:

Well you found several bugs.  First the crash is because a NULL pointer dereference when attempting to revert the entry cache when something goes wrong.  This is a one line fix, but I will open a new bug to track that.  The other issue with the escaping isa bit more complicated.

First you can delete the entry is you do this:

# ldapmodify ...
dn: cn=\ specialgroupname1,ou=groups,dc=example,dc=com
changetype: delete

If you use "/20" openldap client library will convert it to space before it reaches the server.  That's a not bug in the server, and I'm not sure its a bug at all.  You have have to escape it as above.  What is interesting is that when you use "\ " openldap converts it to "/20".  So all you have to do is just use "\ " to escape the space when deleting the entry.

But...

I then found another much more serious bug.  So when you add an entry with an escaped space as the first character in the DN it is correctly put into memory (entry cache) and written to disk, but if you restart the server and try to access this entry (like trying to delete it) then the server improperly parses the index when the entry is moved into the entry cache.  So the delete will work, but it does not update the entryrdn index.  So trying to add the same entry back fails because the entryrdn index and id2entry are now corrupted

This is how the RDN should look:
  
    - Raw:        cn=\20specialgroupname1
    - Normalized: cn= specialgroupname1

What happens is when we read the entryrdn index after a server restart, these values get normalized twice and it changes the in-memory entry to have an RDN like:

    - Raw:        cn= specialgroupname1
    - Normalized: cn=specialgroupname1   (bad!!!!)

This also impacts reindexing, and that process also does not handle the escaped space either.  So after reindexing the entry will also "disappear" from a client point of view because the RDN is incorrectly written to the entryrdn index file.

I am still working on this, but it is not a trivial fix.  I have not found yet where things are breaking, but it appears to be because we normalize the RDN twice.

Fixed upstream

With build 389-ds-base-1.4.3.16-2.module+el8.4.0+8803+fd0f8fe3.x86_64

 # PYTHONPATH=src/lib389/ py.test -s -v dirsrvtests/tests/suites/syntax/acceptance_test.py::test_dn_syntax_spaces_delete
re-exec with libfaketime dependencies
========================================================= test session starts ==========================================================
platform linux -- Python 3.6.8, pytest-6.1.2, py-1.9.0, pluggy-0.13.1 -- /usr/bin/python3.6
cachedir: .pytest_cache
metadata: {'Python': '3.6.8', 'Platform': 'Linux-4.18.0-249.el8.x86_64-x86_64-with-redhat-8.4-Ootpa', 'Packages': {'pytest': '6.1.2', 'py': '1.9.0', 'pluggy': '0.13.1'}, 'Plugins': {'metadata': '1.10.0', 'html': '3.0.0', 'libfaketime': '0.1.2'}}
389-ds-base: 1.4.3.16-2.module+el8.4.0+8803+fd0f8fe3
nss: 3.53.1-11.el8_2
nspr: 4.25.0-2.el8_2
openldap: 2.4.46-16.el8
cyrus-sasl: 2.1.27-5.el8
FIPS: disabled
rootdir: /mnt/tests/rhds/tests/upstream/ds/dirsrvtests, configfile: pytest.ini
plugins: metadata-1.10.0, html-3.0.0, libfaketime-0.1.2
collected 2 items                                                                                                                      

dirsrvtests/tests/suites/syntax/acceptance_test.py::test_dn_syntax_spaces_delete[props0-cn=\\20leadingSpace,ou=Groups,dc=example,dc=com] INFO:lib389.topologies:Instance with parameters {'ldap-port': 38901, 'ldap-secureport': 63601, 'server-id': 'standalone1', 'suffix': 'dc=example,dc=com'} was created.
PASSED
dirsrvtests/tests/suites/syntax/acceptance_test.py::test_dn_syntax_spaces_delete[props1-cn=trailingSpace\\20,ou=Groups,dc=example,dc=com] PASSEDInstance slapd-standalone1 removed.


========================================================== 2 passed in 17.93s ==========================================================

Marking as verified:tested

verified:tested (see comment 10) with build 389-ds-1.4-8040020201125182123.866effaa / 389-ds-base-libs-1.4.3.16-2.module+el8.4.0+8803+fd0f8fe3.x86_64
-> marking as VERIFIED

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (389-ds:1.4 bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:1835