I did some further investigations and noted that the owncloud.file_locks table had some more rows where the lock was <> 0, but not 1:
SELECT * FROM owncloud.file_locks WHERE file_locks.lock<>0;
which resulted in:
+-------+------+----------------------------------------+------------+
| id | lock | key | ttl |
+-------+------+----------------------------------------+------------+ | 14 | -1 | files/0e3e13890e7b79a0edc572f53b262079 | 1459283811 | | 15 | -1 | files/4f8cbf29cadcc31429f83d792e806885 | 1459283811 | | 89 | 26 | files/e96e1dcb01f6d44a74247b4ec38f0170 | 1496838714 | | 22846 | 27 | files/46e069d0509232e543a2112007e46765 | 1496838719 | | 22848 | 26 | files/bc4e386d83896b627f63b4e7f48c2d1e | 1496838719 | | 23877 | 25 | files/27de4bb5c6042f2a920e605c9884fdcd | 1496840605 | +-------+------+----------------------------------------+------------+
I deleted the rows where the lock value is -1
DELETE FROM owncloud.file_locks WHERE id=14;
DELETE FROM owncloud.file_locks WHERE id=15;
This solved the problem that I was encountering.
Note that there are also files with a lock value of 25, 26, and 27. I did not research the meaning of these values yet, nor the meaning of -1.