Permanent file status "This file is locked" after OnlyOffice online editor crashes

[zerolabnet]

How can I manually remove a file lock status?

ownCloud	Infinite Scale
Edition	Community
Version	4.0.0+3c7bae407
Web client version	8.0.0-alpha.4

[micbar]

This is supposedly a WOPI lock due to an open web Editor.

The web Editor will release the lock after the Editor has been closed.

If the lock is stale, the TTL is 30 min. After that, the lock will be released.

[zerolabnet]

I understand that this lockdown was put in place by the WOPI server.

OnlyOffice crashed and I can't release the lock by closing the file, it's not open.

The setting is in wopiserver.conf.dist (from examples/ocis_wopi):

# WOPI lock expiration time [seconds]
wopilockexpiration = 3600

It's been 9 hours, the timeout lock has not been released. How can I manually remove a file lock status?

[wkloucek]

@zerolabnet could you please do a folder listing while having the dev tools open. Then you need to look for the remote.php/dav/spaces/xxx PROPFIND request and look at the response / preview:

You should see a lockdiscovery entry with a timeout property. What does it state?

[zerolabnet]

    <d:response>
        <d:href>/remote.php/dav/spaces/d13c8bc6-b583-456b-9fcf-66d9fd5fcf7b$1047d316-24b7-424c-bbd0-14d5610f9b3f/example.xlsx</d:href>
        <d:propstat>
            <d:prop>
                <oc:permissions>RDNVWZP</oc:permissions>
                <oc:favorite>0</oc:favorite>
                <oc:fileid>d13c8bc6-b583-456b-9fcf-66d9fd5fcf7b$1047d316-24b7-424c-bbd0-14d5610f9b3f!f10d0082-5e36-40f9-95c2-b7b443030b07</oc:fileid>
                <oc:file-parent>d13c8bc6-b583-456b-9fcf-66d9fd5fcf7b$1047d316-24b7-424c-bbd0-14d5610f9b3f!1047d316-24b7-424c-bbd0-14d5610f9b3f</oc:file-parent>
                <oc:name>example.xlsx</oc:name>
                <d:lockdiscovery>
                    <d:activelock>
                        <d:locktype>
                            <d:write/>
                        </d:locktype>
                        <d:lockscope>
                            <d:exclusive/>
                        </d:lockscope>
                        <d:depth>Infinity</d:depth>
                        <d:owner>OnlyOffice</d:owner>
                        <d:timeout>Second-0</d:timeout>
                        <d:locktoken>
                            <d:href>opaquelocktoken:797356a8-0500-4ceb-a8a0-c94c8cde7eba Q293RkJsd3NMaUVsSE54U3ZhU0Jxdz09</d:href>
                        </d:locktoken>
                    </d:activelock>
                </d:lockdiscovery>
                <oc:owner-id>admin</oc:owner-id>
                <oc:owner-display-name>Sergey N</oc:owner-display-name>
                <oc:privatelink>https://example.org/f/d13c8bc6-b583-456b-9fcf-66d9fd5fcf7b$1047d316-24b7-424c-bbd0-14d5610f9b3f%21f10d0082-5e36-40f9-95c2-b7b443030b07</oc:privatelink>
                <d:getcontentlength>10949</d:getcontentlength>
                <oc:size>10949</oc:size>
                <d:getlastmodified>Thu, 27 Apr 2023 20:11:10 GMT</d:getlastmodified>
                <d:getetag>"1688c9c24bb67a4289bf4f3232bbf8a2"</d:getetag>
                <d:getcontenttype>application/vnd.openxmlformats-officedocument.spreadsheetml.sheet</d:getcontenttype>
                <d:resourcetype></d:resourcetype>
                <oc:tags></oc:tags>
            </d:prop>
            <d:status>HTTP/1.1 200 OK</d:status>
        </d:propstat>
        <d:propstat>
            <d:prop>
                <d:activelock></d:activelock>
                <oc:shareroot></oc:shareroot>
                <oc:share-types></oc:share-types>
                <oc:downloadURL></oc:downloadURL>
            </d:prop>
            <d:status>HTTP/1.1 404 Not Found</d:status>
        </d:propstat>
    </d:response>

[wkloucek]

Nice, thanks!

We now need to check if 0 means:

• lock is already expired
• lock does never expire

[wkloucek]

From what I got from http://www.webdav.org/specs/rfc2518.html#ELEMENT_activelock and http://www.webdav.org/specs/rfc2518.html#HEADER_Timeout, 0 means expired lock.

Maybe we're violating the the Webdav spec:

If the timeout expires then the lock may be lost.
Specifically, if the server wishes to harvest the lock upon time-out, 
the server should act as if an UNLOCK method was executed by the server 
on the resource using the lock token of the timed-out lock, 
performed with its override authority. 
Thus logs should be updated with the disposition of the lock, 
notifications should be sent, etc., 
just as they would be for an UNLOCK request.

(http://www.webdav.org/specs/rfc2518.html#rfc.section.9.8.p.6)

[wkloucek]

From what I see in the oC Web code, Web is not checking the timeout property, but expects the activelock to go away. If it sits there with a <d:timeout>Second-0</d:timeout>, Web still treats it like it's locked. So no deletion / renaming / moving is possible in the UI (even if the backend UI would allow it).

@JammingBen Could you please confirm this?

[JammingBen]

Oh yes, this is correct. I didn't even know there is a timeout property. ~Since it seems to be part of the WebDAV spec, I'd consider this as a bug in Web. I'll create an issue for it in the Web repo, thanks for the hint!~ -> nevermind, probably a server concern.

[wkloucek]

Oh yes, this is correct. I didn't even know there is a timeout property. Since it seems to be part of the WebDAV spec, I'd consider this as a bug in Web. I'll create an issue for it in the Web repo, thanks for the hint!

No, we're still checking that. Probably the RFC says, that the lock should go away when expired. In this case it's a backend api bug

[wkloucek]

oC10 and sabre dav do not return expired locks. This seems to be a oCIS api bug

[JammingBen]

According to the official spec:

A client must not assume that just because the time-out has expired the lock has been lost.

You're right, the client should not make any assumptions based on an expired timeout.

[ScharfViktor]

I could reproduce it. Steps:

• user einstein creates file new.txt and locks file for (30s) curl -XLOCK "https://localhost:9200/remote.php/dav/files/einstein/new.txt" -ueinstein:relativity -H "Content-Type: application/json" -H "timeout: Second-30" -d"<?xml version='1.0' encoding='UTF-8'?><d:lockinfo xmlns:d='DAV:'><d:lockscope><d:shared/></d:lockscope></d:lockinfo>" -vk
• wait 30 sec and get file curl -XPROPFIND "https://localhost:9200/remote.php/dav/files/einstein/new.txt" -ueinstein:relativity -H "Content-Type: application/json" -vk

Actual result: the lock is not released <d:timeout>Second-0</d:timeout>

web blocks actions like move or delete that is correct for locked file. but it's not actually blocked. @zerolabnet you can just do action like sharing or editing file content and file would be unlock

https://github.com/owncloud/ocis/assets/84779829/c89f2ec8-7306-46db-a2c0-07cad8c228af

CC @kobergj

[kobergj]

The issue is the PROPFIND:

When using method GetLock in decomposedfs, the server will check for expiry and remove the lock if it is expired. However if calling GetMD in decomposedfs (e.g. when stating a resource) the lock will just be added to the response, without checking for expiry.

Action item: Unexported decomposedfs function readLocksIntoOpaque should use ReadLock to get the the lock instead of assembling it itself (or should check for expiry if that is not possible, but first option is preferred)

[wkloucek]

web blocks actions like move or delete that is correct for locked file. but it's not actually blocked. @zerolabnet you can just do action like sharing or editing file content and file would be unlock

@ScharfViktor Do you know a similar method / workaround for Office files that will be opened with OnlyOffice?

[ScharfViktor]

@ScharfViktor Do you know a similar method / workaround for Office files that will be opened with OnlyOffice?

do you mean how to delete Second-0 lock for office files? if yes, sharing or creating tag for file should be help

[wkloucek]

do you mean how to delete Second-0 lock for office files? if yes, sharing or creating tag for file should be help

As far as I know, sharing is not possible while the file is locked. Tags I don't know...

[ScharfViktor]

As far as I know, sharing is not possible while the file is locked. Tags I don't know...

when we have real lock -> yes, we cannot share (423 error) and create tag (500 error - is bad) but buttons share create tag is available on web, so you can just try to share.

when we have Second-0 lock -> web thinks that it is real lock and hides buttons instead of share, create tag. So I suggested to do available action on web to unlock file

[micbar]

@kobergj Maybe i missed the PR, is that already fixed in reva?

[kobergj]

No not fixed yet. I'll do it today :+1:

[micbar]

Ok, thanks for taking care. I just saw the new tests pull request.

@ScharfViktor also opened a lot of other bug tickets related to locking. Seems like a good opportunity to address them in a bulk mode.