nextcloud / nextcloud/groupfolders
Sharing sidebar (Advanced Permissions) fails with xmlParseEntityRef: no name when a group name contains &
Nobody has claimed this yet.
- Dominant language
- PHP
- Stars
- 343
- Forks
- 106
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 34
Description
How to use GitHub
Please use the 👍 reaction to show that you are affected by the same issue.
Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
Subscribe to receive notifications on status change and new comments.
Steps to reproduce
On a Nextcloud instance, have a group whose name contains an unescaped ampersand, e.g. Finanzen & Controlling. In our case the group is synced from LDAP, so renaming it in Nextcloud is not an option.
Create or open a Team folder with Advanced Permissions enabled and entitle a group/user to manage permissions on it.
In the Files app, open the Sharing sidebar on a file or subfolder inside that Team folder and switch to the Advanced Permissions tab to add a rule.
Expected behaviour
The sidebar loads and lets me add ACL rules. Group, team, user display names, and paths containing XML-significant characters (&, <, >, ", ') should be properly XML-escaped in the server response and rendered correctly in the UI.
Actual behaviour
The Advanced Permissions sidebar fails to load. The browser console shows a libxml2 parse error coming from SharingSidebarView:
app: "groupfolders"
error: ss: xmlParseEntityRef: no name on line 6, column 495
at Zn (https://mycloud.de/custom_apps/groupfolders/js/SharingSidebarView-TyF_L0j5.chunk.mjs:62:366)
at async V (https://mycloud.de/custom_apps/groupfolders/js/SharingSidebarView-TyF_L0j5.chunk.mjs:71:5544)
level: 2
The response body being parsed contains the raw group name with an unescaped & (something like ...Finanzen & Controlling...), which is not well-formed XML and aborts parsing. Testing with a local group without & in its name confirms this: the sidebar works immediately. Configuring the same rules via occ groupfolders:permissions works fine because it bypasses the XML response path.
The fix should be to XML-escape names (& → &, etc.) before emitting them into the sidebar's response — e.g. htmlspecialchars($name, ENT_XML1 | ENT_QUOTES, 'UTF-8') or equivalent — so that LDAP-provisioned groups with special characters in their names are handled correctly.
Server configuration
Client details:
- OS: Windows 11
- Browser: Edge
- Version: 145.0.3800.82
- Device: desktop
Server details
Web server: Apache
Database: Tested on MySQL
PHP version: Tested on 8.3.28
Nextcloud version: Tested on 33.0.0
Updated from an older Nextcloud/ownCloud or fresh install: updated from 32
Where did you install Nextcloud from: Docker image
List of activated apps:
deck, groupfolders, richdocuments, files_sharing
Nextcloud configuration:
Are you using an external user-backend, if yes which one: LDAP
Are you using encryption: no
Are you using an external storage, if yes which one: none
Logs
Nextcloud log
{ "app": "groupfolders", "error": "ss: xmlParseEntityRef: no name on line 6, column 495 at Zn (https://mycloud.de/custom_apps/groupfolders/js/SharingSidebarView-TyF_L0j5.chunk.mjs:62:366) at async V (https://mycloud.de/custom_apps/groupfolders/js/SharingSidebarView-TyF_L0j5.chunk.mjs:71:5544)", "level": 2 }Include any additional surrounding entries from data/nextcloud.log captured when opening the sidebar.
Browser log
a) JavaScript console:
Request URL and method
PROPPATCH /remote.php/dav/files/B1F435E7-5E16-46C5-BDFC-42E455ED6549/FB%2010%20-%20Kinderbetreuung%2C%20Schule%20%26%20Bildung/54 HTTP/1.1 Accept: */* Accept-Encoding: gzip, deflate, br, zstd Accept-Language: de,de-DE;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6 Connection: keep-alive Content-Length: 1158 Content-Type: text/plain;charset=UTF-8 Cookie: __Host-nc_sameSiteCookielax=true; __Host-nc_sameSiteCookiestrict=true; nc_username=B1F435E7-5E16-46C5-BDFC-42E455ED6549; oc_sessionPassphrase=Ldwl9KwqZzOKzUwRrEGtTKTtyNfUSAiuaX%2BT3rQ81lMx0RFwzMVDJRi1a3jo49DI1cJOYQuVMJfHLbrZakE46Go3y%2F9g9LiC%2BOhj7iEAvzywjU7sVee%2Bk2HCVLvCKLM6; ocrzmhwbqkxi=3f14154900c94d7e1139611fd901f93e; nc_token=eVh4GNYuT8oBfys%2F%2Bnqi06SLE6fjt094; nc_session_id=3f14154900c94d7e1139611fd901f93e Host: mycloud.de Origin: https://mycloud.de Sec-Fetch-Dest: empty Sec-Fetch-Mode: cors Sec-Fetch-Site: same-origin User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36 Edg/147.0.0.0 X-Requested-With: XMLHttpRequest requesttoken: bKr4AGGuiTWF+1t0jTC9VLdWSjApAIDHDo1djJYu060=:A/m6dDj05E30qB8xu1OWGoMZIGVdedGdXv8YyO8ZpOc= sec-ch-ua: "Microsoft Edge";v="147", "Not.A/Brand";v="8", "Chromium";v="147" sec-ch-ua-mobile: ?0 sec-ch-ua-platform: "Windows"Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the server response consumed by SharingSidebarView and compare it with the failing XML parse for a group name containing an ampersand. Use the reported Advanced Permissions sidebar flow and the existing groupfolders:permissions command as references. Done means the response remains well-formed and the sidebar loads and displays names and paths containing XML-significant characters.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- php
- Domain
- api, backend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 72/100