Thank you for reporting this issue! I have been able to confirm the issue on:
Version: 4.2.0.0.alpha0+Build ID: b0a1666f756aa5f5315366eca9d7d02ddd55d2b
Date:   Tue May 28 08:51:01 2013 +0300 
Platform: Bodhi Linux 2.2 x64

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
As I've been able to confirm this problem I am marking as:

New (confirmed)
Minor - while it's annoying you can't open it this way through terminal, you can open it just find opening LibreOffice first, then going file -> open and using the GUI to do it.
High - Because it's still an inability to open marking as High


+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link:
https://wiki.documentfoundation.org/QA/BugTriage and join us on freenode at #libreoffice-qa

There are also other ways to get involved including with marketing, UX, documentation, and of course developing -  http://www.libreoffice.org/get-help/mailing-lists/. 

Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material

Same behavior if opening through File Manager (e.g.Nautilus).
Workaround: mounting that directory from fstab or rc.local to local directory :-)

ign_christian - thanks for that catch! I forgot I do mount my samba locally....I still think priority fits since there is a workaround

Thank you for confirm...
A happy outcome is worth waiting for. ;-)
This Bug was the main reason to cancel libreOffice with Linux in our company.

See my analysis in bug 67527 comment 16 & 17. For short: On some systems after opening the share in Nautilus, suddenly the CLI also starts to work.

Note that there can be two different software stacks involved when LO accesses a file via "GNOME VFS" (e.g., with sftp or smb URL schemes) on Linux:

* One stack is used when the LO build is configured with --enable-gnome-vfs.  It uses GNOME's legacy GnomeVFS module for file access.  The LO builds available via <http://www.libreoffice.org/download/> are exclusively of this kind (because this guarantees they work out of the box even on rather old machines).  LO builds of this kind can be identified by a file named by the wildcard pattern program/*ucpgvfs*.so in their installation.

* The other stack is used when the LO build is configured with --enable-gio.  It uses GNOME's modern GIO/GVFS module for file access.  Linux distro's LO builds, as well as likely many nightly tinderbox builds (available at <http://dev-builds.libreoffice.org/daily/>), are typically of this kind.  LO builds of this kind can be identified by a file named by the wildcard pattern program/*ucpgio*.so in their installation.

(A potential third kind would be LO builds configured with --disable-gnome-vfs --disable-gio that do not allow for file access via "GNOME VFS" at all.  There /might/ be nightly tinderbox builds of this kind.  They could be identified by having no file named by either of the wildcard patterns program/*ucpgvfs*.so nor program/*ucpgio*.so in their installation.)

These two kinds can exhibit completely different problems, so it is always important to state what kind is involved when encountering a specific problem, and it makes no sense to compare different LO versions of different kind for "worked in the past, broken now" insight.


Now, one problem with LO builds of the second, --enable-gio kind that was at least present since LO 4.0 is that when LO is requested to access a file via "GNOME VFS" on a share that is not yet mounted, LO will not try to mount that share (where mounting will typically result in a GUI dialog asking for credentials).  This had been fixed on master towards LO 4.2 in June with <http://cgit.freedesktop.org/libreoffice/core/commit/?id=4d8bf09305fc4e4bd652187aac0a02398413ba65> "Always try to mount in gio::Content::getGFileInfo" and has now been backported to libreoffice-4-0 towards LO 4.0.6 (<http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-0&id=20b937fe53d6eebf1d2546f228f9209f75612ba6>) and libreoffice-4-1 towards LO 4.1.2 (<http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-1&id=08ab6d26e082c1646de73b347058fd9063570e13>).

(In reply to comment #6)
> Now, one problem with LO builds of the second, --enable-gio kind that was at
> least present since LO 4.0 is that when LO is requested to access a file via
> "GNOME VFS" on a share that is not yet mounted, LO will not try to mount
> that share (where mounting will typically result in a GUI dialog asking for
> credentials).  This had been fixed on master towards LO 4.2 in June with
> <http://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=4d8bf09305fc4e4bd652187aac0a02398413ba65> "Always try to mount in
> gio::Content::getGFileInfo" and has now been backported to libreoffice-4-0
> towards LO 4.0.6
> (<http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-
> 0&id=20b937fe53d6eebf1d2546f228f9209f75612ba6>) and libreoffice-4-1 towards
> LO 4.1.2
> (<http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-
> 1&id=08ab6d26e082c1646de73b347058fd9063570e13>).
Indeed, that fixes the problem for me. Tested with 4.1.1 & 4.1.2 from repositories on Fedora 19 (64-bit). Thanks a lot.
A Note for KDE users: It won't work unless you manually install 'gvfs-smb' package for Fedora, or 'gvfs-backends' package for Ubuntu.

(In reply to comment #7)
> A Note for KDE users: It won't work unless you manually install 'gvfs-smb'
> package for Fedora, or 'gvfs-backends' package for Ubuntu.
Just tried with Ubuntu 13.10 (64-bit), and it also needs 'libreoffice-gnome' package to be installed.

*** This bug has been marked as a duplicate of bug 70712 ***

Setting this based on Maxim's bug 70712 comment 6 where he stated "Bug 49776 is either fixed as per Bug 49776 comment 6, or a variation of (one of the issues discussed in) Bug 67527."