This error has existed for some time now (maybe even back in 2.0). We had hoped
it would be fixed in the course of the reimplementation of locking on OOo 3.0
but it's still there. 

1. Create an .odt text document and save it on a CIFS share

2. Lock this document from Linux, e.g. by opening it with OOo 2.x.

3. Try to open the document from a different machine (Windows or Linux; it seems
to depend on the kernel version, so it may not happen with all versions of
Windows/Linux) with OOo 3.0. Instead of opening the document read-only or
presenting a meaningful error message, OOo presents the filter selection dialog
as if you were accessing an unknown file type. This is completely nonsensical.

Note: If you perform step 2 from Windows (i.e. open the file with OOo 2.x under
Windows), then attempting to open it under Linux gives an I/O Error error
message. While this is technically correct and certainly better than the filter
selection, it is just as unhelpful and confusing for ordinary users.

IOW: The 4 scenarios "Lock .ODT file via Windows/Linux with system file locking
on a CIFS share and attempt to open the locked file with OOo 3.0 on
Linux/Windows" currently do not all produce reasonable results. This needs to be
fixed. 

This is NOT the same as re-introducing support for system file locking. Every
well-behaved application, even if it does not support system file locking, needs
to react appropriately to all possible E... error conditions returned by system
calls such as open(2), as they occur when attempting to access a file on a CIFS
share protected by a mandatory lock.

Please do not turn this bug into a "reintroduce support for system file locking"
feature request. Such a feature would probably take a long time to implement.
This is AFAICT a plain bug in dealing with error codes returned from system
calls and as such should be fixed quickly.

On a related note, don't waste your time posting "workarounds" resulting in
disabling (mandatory) locking on the CIFS server. This is beside the point. this
issue is just to report OOo's improper handling of error conditions, not a
support request asking for ways to avoid the occurence of these conditions.