423 Locked #884
Comments
|
How odd, I must admit I've never seen that. Looking at the URL, they suggest using redis as the permanent solution... but the snap uses redis. I can't immediately explain what's going on, so let's take a look at some logs, if you don't mind. First of all, can you paste the output from this script in here? Also, the Nextcloud log is in the data directory, which by default is Also, yeah, restoring backups in DO might wreak havoc with Nextcloud's file tracking, be very careful. |
|
Any chance this could be related? nextcloud/server#9001 |
|
Yes I did read that about Redis and then suspected that the snap was already using it.. so thanks for the confirmation. Actually was not expecting you to respond so quickly and I already restored the droplet from the same backup 19 hours ago. So unfortunately, all logs are gone. One thing I noticed was an error on creating my test file. As I said, I created the test file in the browser, using the plus icon and creating a new file of 0 bytes. I saw an error about a file of zero size just before the lock error. So I wonder if that was related. As for the redis race 9001 issue you asked about, I can't say.. although that says upload a bigger file, and as I said mine was actually an zero byte file. As for restoring the droplet from a a back up, the only error I saw in the web ui stated that something wasn't right because my last cron job had run 19 hours ago, instead of 15 minutes ago. But as soon as the first cron ran, that warning disappeared and all seemed well. As for my files being deleted, I believe this may be related to a setting somewhere where I said to sync deletes. I will let you know if i see any odd behavior and check logs this time. Thanks again for maintaining this snap! |
|
ok having this error again after moving folders. I am dealing with a sudden loss of available disk space and so looking for any larger tmp files I can remove and came across this: 139M Feb 3 03:44 /var/snap/nextcloud/11139/mysql/epi.err Which surprised me because I did not think the snap is using mysql. |
|
Something keep gobbling up disk such that / would go to 100% was hanging so I deleted this 153m cache file: and was then able to stop the snap now a
where as before it kept going to 0m available after I would free up space |
|
Ok here are the previously requested log files:
|
|
Ok now installed ncdu to look for big files and found some here:
(Tailing the nextcloud.log I did see 'trash' quite a few times.) When I look in that trash dir I see the same file many times: The filename ends in .3mf so the string that follows: |
|
Indeed, the snap uses mysql. Any chance all your problems stem from having a full disk? You can definitely try emptying Nextcloud's trash if you're comfortable with that: |
|
Ok happy to empty the trash.. tho I have a strong feeling that the trash is exactly what caused the full disk in the first place. |
|
ok deleted trash for all users |
|
so that freed about 2gb, but the trash mentioned earlier remains at 19.7gb: /var/snap/nextcloud/common/nextcloud/data/__groupfolders/trash/2 |
|
One of my machines just connected and began to sync, threw 403 forbidden errors, and now the disk space is full again. This is pretty ruinous, I'm not sure what to do. I stopped the snap. |
|
group folders trash instantly grew by 2gb. /var/snap/nextcloud/common/nextcloud/data/__groupfolders |
|
I got a nice error trying to empty the trash. Looking for Redis logs.. root@epi:/# nextcloud.occ trashbin:cleanup |
|
What the heck. Is that sync moving a huge directory around, perhaps? Something that Nextcloud might translate into new uploads as well as deletions? That redis error definitely sounds like a full disk. |
|
I would not call it huge, but the lock problems did begin with moving a folder, a groupfolder. I suspect this problem may related to trash and groupfolder in nextcloud 15 and have posted the issue there. Sorry for the distraction as I do not believe this issue has to do with the nextcloud snap. |
|
Maybe not related, but in the blog post announcing the recent updates https://nextcloud.com/blog/time-to-update-nextcloud-15.0.4-14.0.7-and-13.0.11-are-here/ they talk about this improvement:
Maybe updating to 15.0.4 helps in some way... |
|
@kyrofa any recommendations on how I might remove & re-install the nextcloud snap on the same server? I have copied out all of my data and plan to just add it to a fresh install of nextcloud server. |
|
@winstonford check out |
|
After a power failure I got the following:
|
|
A similar problem occurred to me today. My nextcloud-client [on Debian GNU/Linux 9.12 (stretch) ] : On the server side. Why does this happen without anything changing (by server at least) ? |
|
Same here. Using Redis store. My cache config looks like this: |
|
I only use
{
"system": {
"instanceid": "***REMOVED SENSITIVE VALUE***",
"passwordsalt": "***REMOVED SENSITIVE VALUE***",
"secret": "***REMOVED SENSITIVE VALUE***",
"trusted_domains": [
"*******"
],
"datadirectory": "***REMOVED SENSITIVE VALUE***",
"dbtype": "mysql",
"version": "17.0.2.1",
"overwrite.cli.url": "http:\/\/**********",
"htaccess.RewriteBase": "\/",
"dbname": "***REMOVED SENSITIVE VALUE***",
"dbhost": "***REMOVED SENSITIVE VALUE***",
"dbport": "",
"dbtableprefix": "oc_",
"dbuser": "***REMOVED SENSITIVE VALUE***",
"dbpassword": "***REMOVED SENSITIVE VALUE***",
"installed": true,
"mysql.utf8mb4": true,
"memcache.local": "\\OC\\Memcache\\APCu",
"mail_smtpmode": "smtp",
"mail_smtpsecure": "ssl",
"mail_sendmailmode": "smtp",
"mail_domain": "***REMOVED SENSITIVE VALUE***",
"mail_from_address": "***REMOVED SENSITIVE VALUE***",
"mail_smtphost": "***REMOVED SENSITIVE VALUE***",
"mail_smtpport": "465",
"mail_smtpauth": 1,
"mail_smtpname": "***REMOVED SENSITIVE VALUE***",
"mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
"maintenance": false,
"theme": "",
"loglevel": 2
}
} |
|
I found the problem in my case. I switched to Redis recently, but in the db there were still lock entries. After removing them, error was gone. |
|
Same issue here. Using NC 18.0.4 with REDIS already enabled. Uploading a high number of files generates those warnings after one minute. This issue is very frustrating! Is there any way I can check? Nothing is logged, wehn the error occurs. My config: ServerInfo: {
"ocs":{
"meta":{
"status":"ok",
"statuscode":200,
"message":"OK"
},
"data":{
"nextcloud":{
"system":{
"version":"18.0.4.2",
"theme":"",
"enable_avatars":"yes",
"enable_previews":"yes",
"memcache.local":"\\OC\\Memcache\\APCu",
"memcache.distributed":"none",
"filelocking.enabled":"yes",
"memcache.locking":"\\OC\\Memcache\\Redis",
"debug":"no",
"freespace":162875158528,
"cpuload":[
0.16,
0.29,
0.43
],
"mem_total":8168100,
"mem_free":7416776,
"swap_total":2097148,
"swap_free":2066808,
"apps":{
"num_installed":45,
"num_updates_available":0,
"app_updates":[
]
}
},
"storage":{
"num_users":87,
"num_files":28225,
"num_storages":104,
"num_storages_local":1,
"num_storages_home":102,
"num_storages_other":1
},
"shares":{
"num_shares":218,
"num_shares_user":40,
"num_shares_groups":0,
"num_shares_link":63,
"num_shares_mail":115,
"num_shares_room":0,
"num_shares_link_no_password":62,
"num_fed_shares_sent":0,
"num_fed_shares_received":1,
"permissions_0_1":"3",
"permissions_3_1":"43",
"permissions_4_1":"68",
"permissions_0_3":"2",
"permissions_3_3":"3",
"permissions_4_3":"14",
"permissions_3_15":"17",
"permissions_4_15":"33",
"permissions_0_19":"12",
"permissions_0_31":"23"
}
},
"server":{
"webserver":"Apache\/2.4.29",
"php":{
"version":"7.2.24",
"memory_limit":2147483648,
"max_execution_time":3600,
"upload_max_filesize":17179869184
},
"database":{
"type":"mysql",
"version":"5.7.29",
"size":44392448
}
},
"activeUsers":{
"last5minutes":7,
"last1hour":8,
"last24hours":16
}
}
}
}Redis Log: |
|
Update: It is working with the native Windows client - Browser issue? |
I just opened nextcloud/server#21073 and nextcloud/server#21074 - sounds like you may be suffering from the same or similar issue. |
|
In my case this error was encountered in a full installation of nextcloud, while trying to delete a folder. I would propose as a stopgap in this case to i) delete the folder from the server (e.g through the command-line); ii) trigger a rescan of the particular directory using php occ files:scan -p "the path of the parent folder" iii) delete the folder from the client if necessary. |
|
This issue is stale because it has been without activity for 60 days. It will be closed after 7 more days of inactivity. |
|
This just happened to me. I'm unsure how to clear |
|
I figured out how to clear that table. But it doesn't solve my problem. |
|
I ended up pruning the files from cli using My issue looked very much like this: https://help.nextcloud.com/t/file-is-locked-how-to-unlock/1883 But the solution did not work for me |
On v15.02 running on digital ocean, and this snap is so well maintained this may be the first problem I have had in a year of using it.
Earlier today I got the error, "Server replied "423 Locked" to "DELETE https://[mydomain.com]/remote.php/dav/files/[myusername]/somefile
After reading this doc https://help.nextcloud.com/t/file-is-locked-how-to-unlock/1883, I noticed in the digital ocean ui that I had a backup from 19 hours ago. So I restored to this backup. All went well, then in the web ui, I created a new empty file, deleted it, and now I am getting the same error.
Then I noticed that while Nextcloud said it was syncing my files, it actually it deleted the folder and files I created today. So I lost a day's work and am a bit concerned.
Does anyone have this 423 lock problem with a snap or know how to troubleshoot it?
The text was updated successfully, but these errors were encountered: