Stray locks not being cleaned: server replied: Locked (ajax cron)

[klausguenter]

Hi there,

I have problems uploading some files via windows 7 client (Version 2.0.2, build 5569) connected with an owncloud 8.2 stable-Server.

The files exist on the client, not on the server. The log file on the client says:

06.11.2015 23:07:35 folder1/xxx.MDB   F:\Cloud1                     Error downloading http://xxx/owncloud/remote.php/webdav/folder1/xxx.MDB - server replied: Locked ("folder1/xxx.MDB" is locked)4,3 MB

1) I wonder why the client has problems to download - it should try to upload.

2) At first I thougt that the file on the client could be in use by another program. But the server says, that the file ist locked, not the client.

Can anyone help me please?

Regards, klausguenter

[simsala]

why is this closed when the problem is still there?

[icewind1991]

@simsala do any of the expired locks have a lock value different than 0?

[icewind1991]

also can you check if OCA\Files\BackgroundJob\CleanupFileLocks exists in oc_jobs

[simsala]

There is this database entry in oc_jobs:

142883 OCA\Files\BackgroundJob\CleanupFileLocks null 1463062502

and yes, there are some expired lock records with values other than zero.

some (around 10) with 1 and one with -1.

[PVince81]

@simsala so it means the TTL logic didn't work. @icewind1991 any idea ?

@simsala assuming you're running 8.2.5 already ?

[simsala]

I am running 9.0.2.

Currently the lock db has 11000 records.

Mostly 0. Seems to me they never get removed.

[dergilb99]

I am running 9.0.2.

"Good" to know I am not the only one facing this or a similar problem:

https://github.com/owncloud/core/issues/25232

(If #25232 is redundant, please delete / close.)

[zedug]

I have the same issue on a fresh install - two files can't be uploaded, with a FileLocked exception in the log Running 9.0.1 server, client is 2.1.1 Cleaned the oc_file_locks table with no effect

In fact I did the clean install because I was facing this problem on 8.0.3 so I deleted the install+DB (it's not a large one and i'm the only user...) and did a fresh install -- and refaced the same issue on the same two files

[PVince81]

@zedug can you tell us more about these two files ? Are they shared files ? Received shares ? Shared directly or through a folder ?

[zedug]

No they are not shared files. I use owncloud to share files between different machines (at home and at work) but I'm the only user on all machines, using the owncloud windows client. There's nothing specific about the files themselves - for example one is a .pdf file, and there's a ton of other pdf's that synchronize with no issues.

[roomanus]

Hi everybody,

same probs here, i updated one of my owncloud instances last Sunday from 8.2.5 to 9.0.4 (physical Ubuntu 14.04 Server, Mysql database). Everything seemed to go fine. Now the windows sync client (2.2.2) is showing these locked messages, all sort of filetypes (pdf, xlsx, docx, etc.), can't really reproduce the error. After truncating the oc_file_locks table (~17000) everything runs without error at the moment.

[roomanus]

2 days after truncating the oc_file_tabe it is filled with about 2000 lines, 3 files are not able to get synced because of locking issue.

[leoauri]

@Cybertinus re: https://github.com/owncloud/core/issues/20380#issuecomment-162300963 Your script works a charm, there is one mistake in the code though.. The line dbuser=$(grep dbname "${ownclouddir}/config/config.php" | cut -d "'" -f 4) should read dbuser=$(grep dbuser "${ownclouddir}/config/config.php" | cut -d "'" -f 4) Cheers

[PVince81]

oc_file_tabe it is filled with about 2000 lines

2000 lines is not a problem. The problem is the lines where the "lock" value is non-zero. You might want to check the "ttl" value for these lines, you can compute the expiration time with this command:

date -d +@timestamp, replace timestamp with the value from the TTL column. For example: date -d +@1465553223 This gives you the time after which the lock is supposed to expire. So if the files still can't be uploaded after that time, then there's a bug in expiration.

But thinking of it, maybe it does expire properly but something else could be re-creating the stray lock.

Would be good to observe the behavior of locks over the span of several hours by running select * from oc_file_locks wherelock!= 0;. Goal is to find out whether the "ttl" value changes after expiration for the same "key". The unique key will always point to the same file.

[typorian]

I have a file that I uploaded via browser to my owncloud, shared it with another user, and now I can not delete it. I found something in the logs as shown below:

{"reqId":"V7f74ZT7smAAAGi06@IAAAAS","remoteAddr":"xxx.xxx.xxx.xxx","app":"webdav","message":"Exception: {\"Message\":\"HTTP\\\/1.1 423 \\\"filename\\\" is locked\",\"Exception\":\"OCA\\\\DAV\\\\Connector\\\\Sabre\\\\Exception\\\\FileLocked\",\"Code\":0,\"Trace\":\"#0 \\\/home\\\/xxxxx\\\/public_html\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Tree.php(179): OCA\\\\DAV\\\\Connector\\\\Sabre\\\\File->delete()\\n#1 \\\/home\\\/xxxx\\\/public_html\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/CorePlugin.php(285): Sabre\\\\DAV\\\\Tree->delete('filename')\\n#2 [internal function]: Sabre\\\\DAV\\\\CorePlugin->httpDelete(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#3 \\\/home\\\/xxxx\\\/public_html\\\/3rdparty\\\/sabre\\\/event\\\/lib\\\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\\n#4 \\\/home\\\/xxxx\\\/public_html\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(459): Sabre\\\\Event\\\\EventEmitter->emit('method:DELETE', Array)\\n#5 \\\/home\\\/xxxx\\\/public_html\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(248): Sabre\\\\DAV\\\\Server->invokeMethod(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#6 \\\/home\\\/xxxx\\\/public_html\\\/apps\\\/dav\\\/appinfo\\\/v1\\\/webdav.php(55): Sabre\\\\DAV\\\\Server->exec()\\n#7 \\\/home\\\/xxxx\\\/public_html\\\/remote.php(138): require_once('\\\/home\\\/xxxx\\\/...')\\n#8 {main}\",\"File\":\"\\\/home\\\/xxxx\\\/public_html\\\/apps\\\/dav\\\/lib\\\/connector\\\/sabre\\\/file.php\",\"Line\":342,\"User\":\"Username\"}","level":4,"time":"2016-08-20T06:42:41+00:00","method":"DELETE","url":"\/remote.php\/webdav\/filename","user":"xxxxxx"}

[PVince81]

@typorian were you able to delete it after one hour ? (the lock expiration)

[typorian]

@typorian [1] were you able to delete it after one hour ? (the lock expiration)

@PVince81

It has been a couple of days and I still have not been able to delete it. I'm not realy sure where to go from here, maybe I'll ask to have owncloud restartet.

[PVince81]

@typorian set owncloud to maintenance mode and have the oc_file_locks table cleared, then set back to normal mode. This would clear any stray locks.

But the thing that is strange is that you seem to be having a lock that doesn't go away. Either it doesn't go away on its own (TTL logic bug) or there is some other process that re-sets the lock on this file over and over again.

Has anyone here been able to test https://github.com/owncloud/core/issues/20380#issuecomment-238156998 on their environments ?

[typorian]

@typorian [1] set owncloud to maintenance mode and have the oc_file_locks table cleared, then set back to normal mode. This would clear any stray locks.

But the thing that is strange is that you seem to be having a lock that doesn't go away. Either it doesn't go away on its own (TTL logic bug) or there is some other process that re-sets the lock on this file over and over again.

@PVince81 from what I see I won't be able to do that, as I don't have shell access to the server, I just have administration access within owncloud itself, as I rent the storage from a company. Or am I missing something?

[PVince81]

@typorian hmm, indeed. From this use case you likely won't be able to do that.

Is this file in a shared folder ? Are other people accessing it / downloading it ?

[typorian]

@typorian [1] hmm, indeed. From this use case you likely won't be able to do that.

Is this file in a shared folder ? Are other people accessing it / downloading it ?

@PVince81 it is a file that was shared in a folder that was not shared. I removed the share to no avail. I tried deleting it with an account that it was shared to, but that did not work either. As far as I know, no one else should be able to access it at this time.

[PVince81]

@typorian are you able to rename or delete move the file ? I guess not

[typorian]

@typorian [1] are you able to rename or delete the file ? I guess not

@PVince81 No, neither rename nor delete. I can download it though, so it's still actually there. Not being able to delete it is the issue that led me here in the first place.

[PVince81]

@typorian okay, so if you can download it it means it has a shared lock on it, not exclusive lock.

Now something comes to mind: the expiry of stray locks is happening when running cron. How is cron run on your system ?

[PVince81]

(check the admin page in OC)

[typorian]

@typorian [1] okay, so if you can download it it means it has a shared lock on it, not exclusive lock.

Now something comes to mind: the expiry of stray locks is happening when running cron. How is cron run on your system ?

@PVince81 At the moment it is set to Ajax and claims cron ran successfully. I can set it to webcron or (system)cron as well.

[PVince81]

@typorian hmm, when using ajax cron it doesn't always run all the jobs, just a few. The reason is that some jobs might take longer and PHP might run into a timeout when run from the web.

Now if you switch to system cron I'm not sure it will work, because your provider needs to be able to trigger OC cron from a system cron job. If they had set it up initially, OC would have automatically switched to that mode already. You could ask your provider if they could switch to system cron for your instance.

[PVince81]

Question to all other reporters for this issue: which cron mode do you have ?

[leoauri]

Also AJAX

[PVince81]

Does anyone here does NOT have ajax cron and still see the issue ?

[typorian]

@typorian [1] hmm, when using ajax cron it doesn't always run all the jobs, just a few. The reason is that some jobs might take longer and PHP might run into a timeout when run from the web.

Now if you switch to system cron I'm not sure it will work, because your provider needs to be able to trigger OC cron from a system cron job. If they had set it up initially, OC would have automatically switched to that mode already. You could ask your provider if they could switch to system cron for your instance.

@PVince81 You are correct, I can not switch to php or system cron apparently. BUT: I tried anyways and it told me after a while that apparently there is a problem with running the cron jobs. I switched back to Ajax, and loaded some random pages in owncloud just to trigger it, and voila: I was just now able to delete the file. I don't generally use the website that much so maybe the issue is that Ajax relies on the web frontend to trigger the jobs, they don't always run as you said and the client maybe does not trigger them at all?

[PVince81]

@typorian okay, that's good to know. So many we need to find a solution for environments that rely solely on ajax cron.

Some ideas:

• find a way to run ajax cron more often
• find a way to prioritize background jobs

CC @DeepDiver1975 @butonic

[anduz]

Don't know if this helps:

Getting: Fatal webdav Exception: {"Message":"HTTP\/1.1 423 ... on ownCloud 9.0.2 (stable) Cron activated (however it says last execution 5 month ago) crontab -u www-data -e /15 * * * \ /usr/bin/php /var/www/owncloud/occ files:scan --all > /dev/null Cronjob runs

[dergilb99]

Question to all other reporters for this issue: which cron mode do you have ?

AJAX

[JetUni]

Also using AJAX. I'll be trying CRON on both my installations.

[zedug]

Also using AJAX. Will try CRON early next week

[PVince81]

Ajax doesn't clean properly, how ironic :wink:

If possible on your system, try always using system cron for more accurate results. There are more and more background jobs being added nowadays to do the work that cannot be done within a single PHP request because it would risk timing out (for example expiring versions, trashbin).

There might still be a slight chance to have ajax cron run more often. So far I noticed that it only runs once per page load. Maybe this could be increased to be done once every 15 minutes within any already open ownCloud page.

[dergilb99]

Ajax doesn't clean properly, how ironic

Drat, you beat me to it.

There might still be a slight chance to have ajax cron run more often.

Well, since I don't really use the web interface, I think it runs perhaps once a month... I guess that's bad? I have a bunch of bookmarks that I check on a regular basis. I added the cron.php. (Is it sufficient to open www.abc.de/owncloud for Ajax to run or do I have to link to the cron.php?)

As soon as my webhoster's promotional "a euro a month" period has passed, I'll will switch to another package that supports cronjobs. I was a bit surprised to see that it has ssl certificates but no cron jons.

There might still be a slight chance to have ajax cron run more often.

What about integrating an AJAX-run-thingy in the clients? If a client detects AJAX based crons, it could offer an option to run the script automatically.

[PVince81]

Is it sufficient to open www.abc.de/owncloud for Ajax to run or do I have to link to the cron.php?

Opening any ownCloud web page as logged in user would run cron.php once, no need to call it directly. Now thinking of it, if you have a computer that is always online you might be able to have something ping the ownCloud server's "cron.php" URL regulariy to force it to run (that might be what webcron is about, not sure).

Every cron.php will run only a few of the jobs in oc_jobs, not all of them, due to the risk of timeouts.

What about integrating an AJAX-run-thingy in the clients?

There used to be a ticket where this was discussed in the past and rejected. I don't remember the reasons. I can't seem to find it. @DeepDiver1975 do you remember ?

[dergilb99]

Opening any ownCloud web page as logged in user would run cron.php once

But if I'm not logged in, I have to call it directly, right?

that might be what webcron is about, not sure

At least that's what I thought it would do, too, after reading the description you guys placed there.

if you have a computer that is always online you might be able to have something ping the ownCloud server's "cron.php"

I'll botch-up something like that with my NAS. Till then, I will use cURL and Windows Task Scheduler to do the magic.

There used to be a ticket where this was discussed in the past and rejected.

I don't know how many are out there who rely solely on the clients. But if they are forced to use AJAX and they don't have the proper means to tinker their way around it, some client based help might circumvent a lot of problems as a second best solution.

Nonetheless, thank you so far for your help!

[e-alfred]

I cleaned the oc_file_locks table, it is empty, but I still get error 423 with certain files:

{"reqId":"8TlQgrXtV+is28PODYIV","remoteAddr":"1.1.1.1","app":"webdav","message":"Exception: {\"Message\":\"HTTP\\\/1.1 423 \\\"workspace\\\/.metadata\\\/.plugins\\\/org.eclipse.core.resources\\\/.projects\\\/sudoku\\\/org.eclipse.jdt.core\\\/state.dat\\\" is locked\",\"Exception\":\"OCA\\\\DAV\\\\Connector\\\\Sabre\\\\Exception\\\\FileLocked\",\"Code\":0,\"Trace\":\"#0 \\\/var\\\/www\\\/owncloud\\\/apps\\\/dav\\\/lib\\\/Connector\\\/Sabre\\\/Directory.php(136): OCA\\\\DAV\\\\Connector\\\\Sabre\\\\File->put(Resource id #271)\\n#1 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(1036): OCA\\\\DAV\\\\Connector\\\\Sabre\\\\Directory->createFile('state.dat', Resource id #271)\\n#2 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/CorePlugin.php(523): Sabre\\\\DAV\\\\Server->createFile('workspace\\\/.meta...', Resource id #271, NULL)\\n#3 [internal function]: Sabre\\\\DAV\\\\CorePlugin->httpPut(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#4 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/event\\\/lib\\\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\\n#5 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(459): Sabre\\\\Event\\\\EventEmitter->emit('method:PUT', Array)\\n#6 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(248): Sabre\\\\DAV\\\\Server->invokeMethod(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#7 \\\/var\\\/www\\\/owncloud\\\/apps\\\/dav\\\/appinfo\\\/v1\\\/webdav.php(56): Sabre\\\\DAV\\\\Server->exec()\\n#8 \\\/var\\\/www\\\/owncloud\\\/remote.php(164): require_once('\\\/var\\\/www\\\/ownclo...')\\n#9 {main}\",\"File\":\"\\\/var\\\/www\\\/owncloud\\\/apps\\\/dav\\\/lib\\\/Connector\\\/Sabre\\\/File.php\",\"Line\":174,\"User\":\"user\"}","level":4,"time":"2016-11-09T12:55:53+00:00","method":"PUT","url":"\/remote.php\/webdav\/workspace\/.metadata\/.plugins\/org.eclipse.core.resources\/.projects\/sudoku\/org.eclipse.jdt.core\/state.dat","user":"user"}

I am running redis as a memcache.

Cron.php is run every 15 minutes by a crontab entry, in the webinterface it says it was run a few minutes ago.

[PVince81]

@e-alfred are you using redis for locking too ? If yes, then oc_file_locks is not used but redis. You might want to clear the redis cache too then.

[e-alfred]

Yes, Redis for both caching and locking. I flushed the Redis cache and will see what happens.

[e-alfred]

@PVince81 The problem still prevails, interestingly only for one user with synced hidden files (Git repositories and Eclipse configuration) I am getting a 423 response for certain files.

Here are two examples:

{"reqId":"EguF+W00ZGHGG+M\/L3+Y","remoteAddr":"1.1.1.1","app":"webdav","message":"Exception: {\"Message\":\"HTTP\\\/1.1 423 \\\"workspace\\\/.metadata\\\/.plugins\\\/org.eclipse.core.resources\\\/.projects\\\/sudoku\\\/org.eclipse.jdt.core\\\/state.dat\\\" is locked\",\"Exception\":\"OCA\\\\DAV\\\\Connector\\\\Sabre\\\\Exception\\\\FileLocked\",\"Code\":0,\"Trace\":\"#0 \\\/var\\\/www\\\/owncloud\\\/apps\\\/dav\\\/lib\\\/Connector\\\/Sabre\\\/Directory.php(136): OCA\\\\DAV\\\\Connector\\\\Sabre\\\\File->put(Resource id #271)\\n#1 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(1036): OCA\\\\DAV\\\\Connector\\\\Sabre\\\\Directory->createFile('state.dat', Resource id #271)\\n#2 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/CorePlugin.php(523): Sabre\\\\DAV\\\\Server->createFile('workspace\\\/.meta...', Resource id #271, NULL)\\n#3 [internal function]: Sabre\\\\DAV\\\\CorePlugin->httpPut(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#4 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/event\\\/lib\\\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\\n#5 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(459): Sabre\\\\Event\\\\EventEmitter->emit('method:PUT', Array)\\n#6 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(248): Sabre\\\\DAV\\\\Server->invokeMethod(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#7 \\\/var\\\/www\\\/owncloud\\\/apps\\\/dav\\\/appinfo\\\/v1\\\/webdav.php(56): Sabre\\\\DAV\\\\Server->exec()\\n#8 \\\/var\\\/www\\\/owncloud\\\/remote.php(164): require_once('\\\/var\\\/www\\\/ownclo...')\\n#9 {main}\",\"File\":\"\\\/var\\\/www\\\/owncloud\\\/apps\\\/dav\\\/lib\\\/Connector\\\/Sabre\\\/File.php\",\"Line\":174,\"User\":\"user\"}","level":4,"time":"2016-11-09T14:52:29+00:00","method":"PUT","url":"\/remote.php\/webdav\/workspace\/.metadata\/.plugins\/org.eclipse.core.resources\/.projects\/sudoku\/org.eclipse.jdt.core\/state.dat","user":"user"}

{"reqId":"la+uRl6ZkWB6uigOyEfH","remoteAddr":"1.1.1.1","app":"webdav","message":"Exception: {\"Message\":\"HTTP\\\/1.1 423 \\\"test\\\/test\\\/test\\\/.git\\\/refs\\\/heads\\\/test\\\" is locked\",\"Exception\":\"OCA\\\\DAV\\\\Connector\\\\Sabre\\\\Exception\\\\FileLocked\",\"Code\":0,\"Trace\":\"#0 \\\/var\\\/www\\\/owncloud\\\/apps\\\/dav\\\/lib\\\/Connector\\\/Sabre\\\/Directory.php(136): OCA\\\\DAV\\\\Connector\\\\Sabre\\\\File->put(Resource id #271)\\n#1 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(1036): OCA\\\\DAV\\\\Connector\\\\Sabre\\\\Directory->createFile('test', Resource id #271)\\n#2 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/CorePlugin.php(523): Sabre\\\\DAV\\\\Server->createFile('teaching\\\/test...', Resource id #271, NULL)\\n#3 [internal function]: Sabre\\\\DAV\\\\CorePlugin->httpPut(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#4 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/event\\\/lib\\\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\\n#5 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(459): Sabre\\\\Event\\\\EventEmitter->emit('method:PUT', Array)\\n#6 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(248): Sabre\\\\DAV\\\\Server->invokeMethod(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#7 \\\/var\\\/www\\\/owncloud\\\/apps\\\/dav\\\/appinfo\\\/v1\\\/webdav.php(56): Sabre\\\\DAV\\\\Server->exec()\\n#8 \\\/var\\\/www\\\/owncloud\\\/remote.php(164): require_once('\\\/var\\\/www\\\/ownclo...')\\n#9 {main}\",\"File\":\"\\\/var\\\/www\\\/owncloud\\\/apps\\\/dav\\\/lib\\\/Connector\\\/Sabre\\\/File.php\",\"Line\":174,\"User\":\"user\"}","level":4,"time":"2016-11-09T14:52:28+00:00","method":"PUT","url":"\/remote.php\/webdav\/test\/test\/test\/.git\/refs\/heads\/test","user":"user"}

[e-alfred]

Okay, I run an occ files:scan --all and now I do not get any locking messages like above anymore.

[Germano0]

owncloud-9.1.1-1.fc24.noarch here. Command occ files:scan --all did not solve the problem

[moscicki]

We have a similar problem on a small auxiliary installation running owncloud 9.1.3. Is this issue understood already and in the pipeline for fixing?

Files are sometimes locked and neither cleaning up the oc_file_locks table occ files:scan --all solves the problem. In this particular server the crons were not run for a long time due to misconfiguration. We corrected that and run the cron job few times by hand while trying to resolve the problem. It did not help.

The TTL entries in oc_file_locks are set to some insanely high values. What should they be normally? 3600s?

The problem appears for a folder which is "External Mount" pointing to the local disk on the same server and then shared with a user by administrator.

Transactional File Locking is not enabled -- should it?

Here are the server error messages.

{"reqId":"anLv5s55dWcTgOOydVOV","remoteAddr":"ip.address","app":"webdav","message":"Exception: {\"Message\":\"HTTP\\\/1.1 423 \\\"Data\\\/AutoGen\\\/GpsPhotoDb\\\/PhotoListByLatLng\\\/6.3 81.2.dat\\\" is locked\",\"Exception\":\"OCA\\\\DAV\\\\Connector\\\\Sabre\\\\Exception\\\\FileLocked\",\"Code\":0,\"Trace\":\"#0 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(1070): OCA\\\\DAV\\\\Connector\\\\Sabre\\\\File->put(Resource id #57)\\n#1 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/CorePlugin.php(511): Sabre\\\\DAV\\\\Server->updateFile('Data\\\/AutoGen\\\/Gp...', Resource id #57, NULL)\\n#2 [internal function]: Sabre\\\\DAV\\\\CorePlugin->httpPut(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#3 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/event\\\/lib\\\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\\n#4 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(459): Sabre\\\\Event\\\\EventEmitter->emit('method:PUT', Array)\\n#5 \\\/var\\\/www\\\/owncloud\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(248): Sabre\\\\DAV\\\\Server->invokeMethod(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#6 \\\/var\\\/www\\\/owncloud\\\/apps\\\/dav\\\/appinfo\\\/v1\\\/webdav.php(56): Sabre\\\\DAV\\\\Server->exec()\\n#7 \\\/var\\\/www\\\/owncloud\\\/remote.php(164): require_once('\\\/var\\\/www\\\/ownclo...')\\n#8 {main}\",\"File\":\"\\\/var\\\/www\\\/owncloud\\\/apps\\\/dav\\\/lib\\\/Connector\\\/Sabre\\\/File.php\",\"Line\":174,\"User\":\"service\"}","level":4,"time":"2017-01-17T18:11:10+00:00","method":"PUT","url":"\/owncloud\/remote.php\/webdav\/Data\/AutoGen\/GpsPhotoDb\/PhotoListByLatLng\/6.3%2081.2.dat","user":"service"}

[PVince81]

@moscicki this issue here is about people using ajax cron where ajax cron doesn't run often enough to trigger the oc_filelock cleaning background job.

If you say that even clearing that table doesn't solve the problem, then it's a problem that has not been reproduced and understood yet. The TTL is set to 3600 here https://github.com/owncloud/core/blob/v9.1.3/lib/private/Lock/DBLockingProvider.php#L100 in the default value.

From my understand it's not that the lock isn't cleared when clearing the table. The problem is that the lock reappears after clearing and stays there.

The posted exception is about an upload (Webdav PUT).

Usually unlocking the lock is triggered after the fclose() from after the upload. If that fails, then it happens during PHP garbage collection. However it was observed that if the upload is aborted and the PHP connection is lost, it is likely that the fclose() code is never reached and also the GC doesn't run any more, or can't run. This was discovered here with PHP 7: https://github.com/owncloud/core/issues/22370.

See https://github.com/owncloud/core/issues/22370#issuecomment-273442712 for possible fixes.

If no connection abortion or timeouts were involved, then the problem might be somewhere else.

[moscicki]

@PVince81: I created a new issue for this because it looks like the exception causing this is different: #26980

[ulfklose]

I do have the same problem since today. I already cleared the database tables

mysql> DELETE FROM oc_file_locks WHERE 1;
Query OK, 0 rows affected (0.00 sec)

but when I try to move a file to another directory using the web interface I get the lock error message and see this in my log

OCA\DAV\Connector\Sabre\Exception\FileLocked: HTTP/1.1 423 "Atzumer Teich.mp4" is locked

Repeating the move procedure results in the same error, no moving possible.