[Solved] User UUIDs too long for DB with app Circles

Hi everyone,

our (productive) Nextcloud instance is LDAP-integrated, therefor internal usernames are UUIDs, e.g. “DA38C804-9357-4FA1-A2CE-B4F06D5F0C26”.
I recently set up Circles, which allows users to create and self-managed group-like “circles” with which files and folders can be shared.

Setting up a circle and adding users to it works just fine.
The problem occurs when trying to share something with a circle, and the symptoms are as follows:

The circle shows up in the sharing interface autocomplete suggestions.
When selected, it’s not added to the shares list; instead, the following error appears at the top of the page:

An exception occurred while executing ‘INSERT INTO oc_circles_shares (creation, circle_id, source, type, headers, author, cloud_id, unique_id, payload) VALUES(NOW(), ?, ?, ?, ?, ?, ?, ?, ?)’ with params [“8c2dc874d0d8ad”, “files”, “”, “{"author":"DA38C804-9357-4FA1-A2CE-B4F06D5F0C26","circleName":"testing","circleUniqueId":"8c2dc874d0d8ad","broadcast":"\\OCA\\Circles\\Circles\\FileSharingBroadcaster"}”, “DA38C804-9357-4FA1-A2CE-B4F06D5F0C26”, null, “f6f55049bfc50659d9139f7327110c59”, “{"id":54,"share":{}}”]: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column ‘author’ at row 1

If you refresh the page, it then shows up in the folder/file shares. It’s also active, so the circle members have access to the shared object. But I have no idea what kind of errors can occur if this failing database record is missing.

This error does not occur when sharing from a local (non-LDAP) user, because the internal ‘author’ field there is a normal username that isn’t too long for the database.

So, I though this could maybe be fixed by modifying the database column accordingly, but I needed to ask before just breaking everything on the first try.

The affected table oc_circles_shares looks like this:

mysql> SHOW COLUMNS in oc_circles_shares;
+-----------+------------------+------+-----+---------+----------------+
| Field     | Type             | Null | Key | Default | Extra          |
+-----------+------------------+------+-----+---------+----------------+
| id        | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| unique_id | varchar(32)      | YES  |     | NULL    |                |
| circle_id | varchar(64)      | NO   |     | NULL    |                |
| source    | varchar(15)      | NO   |     | NULL    |                |
| type      | varchar(15)      | NO   |     | NULL    |                |
| author    | varchar(32)      | NO   |     | NULL    |                |
| cloud_id  | varchar(128)     | YES  |     | NULL    |                |
| headers   | varchar(4000)    | YES  |     | NULL    |                |
| payload   | varchar(4000)    | NO   |     | NULL    |                |
| creation  | datetime         | YES  |     | NULL    |                |
+-----------+------------------+------+-----+---------+----------------+
10 rows in set (0.01 sec)

Do I have any chance of fixing this without affecting existing users/shares?

Any help would be greatly appreciated.

For anyone walking into the same issue in the future, this simple query I used to fix it didn’t seem to have any negative consequences:

ALTER TABLE oc_circles_shares MODIFY author VARCHAR(64);

1 Like

Fixed in next release, thanks for your fix. (Also, sorry, haven’t seen your report before)