Bug 670699 - Can't open files on a Nautilus mounted SMB share
Summary: Can't open files on a Nautilus mounted SMB share
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: gvfs
Version: 14
Hardware: i686
OS: Linux
low
low
Target Milestone: ---
Assignee: Tomáš Bžatek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-01-19 01:52 UTC by Keith Williams
Modified: 2015-03-03 22:57 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-16 21:02:22 UTC
Type: ---


Attachments (Terms of Use)

Description Keith Williams 2011-01-19 01:52:35 UTC
Description of problem: Error message occurs when trying to open files from a password protected smb share via Nautilus


Version-Release number of selected component (if applicable): Nautilus 2.32.2-1, gvfs-smb-1.6.6-1.fc14 (i686)


How reproducible:


Steps to Reproduce:
1. Create a text file on a password protected smb share
2. Open Nautilus via the "Places," "Connect to Server" menu choice
3. Choose service type "Windows share," server "192.168.248.6" (substitute your own IP address, of course), share "memory_card" (substitute your own share), user name "default" (substitute your own), domain name "WORKGROUP" (substitute your own).
4. Click "Connect"
5. Enter a password (in my case neither the specific user nor password matter, but both must be supplied or different error messages arise)
6. Click "Connect"
7. A Nautilus window opens showing the contents of the share
8. Navigate to and "double-click" the text file created in step 1 to attempt to open it.
  
Actual results: An error message, "Could not open the file smb://WORKGROUP;default@….6/memory_card/Colors.txt.  You do not have permission to open the file" appears. 


Expected results: Text file opens in gedit.


Additional info: The share I'm attempting to connect to is exported by a HP L7680 OfficeJet Pro printer.  I can access the share without incident from Microsoft Windows Vista Home Edition.  

I can open the share with the following command: smbclient --user=default //192.168.248.6/memory_card (and actually, the specific user entered does not matter--any user, and any password will work); followed by a password at the next prompt.  From the "smb: \> prompt, I can browse to a file, "get" the file to a local directory and open it.

Strangely enough when I get the error message in Nautilus, if I click "Retry" the contents of the file appear briefly before the error message reappears.

Comment 1 Tomáš Bžatek 2011-01-20 13:30:29 UTC
Can you try copying the file to local disk using Nautilus? Alternatively, `gvfs-copy` can be used for that.

Also, please post output of the `gvfs-info` command.

Comment 2 Keith Williams 2011-01-21 05:44:59 UTC
(In reply to comment #1)
> Can you try copying the file to local disk using Nautilus? Alternatively,
> `gvfs-copy` can be used for that.
> 
> Also, please post output of the `gvfs-info` command.

I tried copying a file from the Nautilus window to my desktop (via drag-and-drop) and received the following error:

Error while copying "myfile".
There was an error copying the file into /home/keith/Desktop.

Under "Show more details": Permission denied

Interestingly enough, if I drag a file from my desktop back into
the Nautilus window, it copies the file just fine.  Also, from 
Nautilus, I can delete files on the remote share as well.  The following command works:

gvfs-copy file:///home/keith/Desktop/myfile3 smb://WORKGROUP\;default\@192.168.248.6/memory_card/

but this one:

gvfs-copy smb://WORKGROUP\;default\@192.168.248.6/memory_card/myfile3 file:///home/keith/Desktop/

yields an error message:

Error copying file smb://WORKGROUP;default.248.6/memory_card/myfile3: Permission denied

The output of the gvfs-info command is as follows (unsure how to specify
this command):

[root@state Documents]# gvfs-info smb://WORKGROUP\;default\@192.168.248.6/memory_card/myfile3
Error getting info: Operation not supported
[root@state Documents]# gvfs-info smb://WORKGROUP\;default\@192.168.248.6/memory_card
Error getting info: Operation not supported
[root@state Documents]# gvfs-info smb://WORKGROUP\;default\@192.168.248.6
Error getting info: Operation not supported
[root@state Documents]# gvfs-info smb://WORKGROUP\;default
Error getting info: Operation not supported
[root@state Documents]# gvfs-info smb://WORKGROUP
Error getting info: Operation not supported
[root@state Documents]# gvfs-info smb://
Error getting info: Operation not supported

Also, please notice this snippet from an "ls -alR" of my home directory:

drwxrwxr-x.  2 keith keith    4096 Jan 10 07:18 .gstreamer-0.10
-rw-rw-r--.  1 keith keith     160 Jan 20 08:22 .gtk-bookmarks
d??????????  ? ?     ?           ?            ? .gvfs
-rw-------.  1 keith keith    6204 Jan 20 08:22 .ICEauthority
drwxrwxr-x.  3 keith keith    4096 Jan 12 15:17 .icedteaplugin
-rw-r--r--.  1 keith keith     635 Jan 20 08:23 .imsettings.log
:ls: cannot open directory keith/.gvfs: Permission denied
-rw-------.  1 keith keith      53 Jan 14 22:48 .lesshst


Thanks for helping with my issue!
-- Keith Laten Williams

Comment 3 Tomáš Bžatek 2011-01-24 14:34:02 UTC
Okay, first thing - never use root within a desktop session. There's no need for this and only brings troubles. GUI applications won't probably work right when spawned from root terminal.

Perhaps your permissions at /home/keith/Desktop/ are wrong due to recent root use?

gvfs-info would show more, you can also try gvfs-cat which will read the file from remote share, not writing anything locally. Syntax is right as you wrote, just run under normal user in a desktop session.

(In reply to comment #2)
> :ls: cannot open directory keith/.gvfs: Permission denied
This is correct, we denied access for users other than current one (including root).

Comment 4 Keith Williams 2011-01-25 03:40:53 UTC
(In reply to comment #3)
> Okay, first thing - never use root within a desktop session. There's no need
> for this and only brings troubles. GUI applications won't probably work right
> when spawned from root terminal.

OK, thanks.

> Perhaps your permissions at /home/keith/Desktop/ are wrong due to recent root
> use?

[keith@state ~]$ ls -l
total 36
drwxr-xr-x.  2 keith keith 4096 Jan 24 02:08 Desktop
drwxr-xr-x. 14 keith keith 4096 Jan 24 20:23 Documents
drwxr-xr-x.  3 keith keith 4096 Jan 24 17:18 Downloads
drwxr-xr-x.  2 keith keith 4096 Jan  9 20:18 Music
drwxr-xr-x.  6 keith keith 4096 Jan 17 09:32 mysql
drwxr-xr-x.  2 keith keith 4096 Jan 20 15:03 Pictures
drwxr-xr-x.  2 keith keith 4096 Jan  9 20:18 Public
drwxr-xr-x.  2 keith keith 4096 Jan  9 20:18 Templates
drwxr-xr-x.  2 keith keith 4096 Jan  9 20:18 Videos

> gvfs-info would show more, you can also try gvfs-cat which will read the file
> from remote share, not writing anything locally. Syntax is right as you wrote,
> just run under normal user in a desktop session.

[keith@state ~]$ gvfs-info smb://WORKGROUP\;default\@192.168.248.6/memory_card
display name: memory_card on 192.168.248.6
edit name: /
name: /
type: directory
size:  3820994560
attributes:
  standard::type: 2
  standard::name: /
  standard::display-name: memory_card on 192.168.248.6
  standard::edit-name: /
  standard::icon: folder-remote
  standard::content-type: inode/directory
  standard::size: 3820994560
  etag::value: 0
  id::filesystem: smb-share:domain=WORKGROUP,server=192.168.248.6,share=memory_card,user=default
  time::modified: 0
  time::modified-usec: 0
  time::access: 0
  time::access-usec: 0
  time::changed: 0
  time::changed-usec: 0
  unix::device: 232967
  unix::inode: 2026404
  metadata::nautilus-icon-view-auto-layout: true
  metadata::nautilus-icon-view-tighter-layout: false

*******************************************************************************

[keith@state ~]$ gvfs-info smb://WORKGROUP\;default\@192.168.248.6/memory_card/myfile3
display name: myfile3
edit name: myfile3
name: myfile3
type: regular
size:  13
attributes:
  standard::type: 1
  standard::name: myfile3
  standard::display-name: myfile3
  standard::edit-name: myfile3
  standard::icon: application-octet-stream, gnome-mime-application-octet-stream, application-x-generic
  standard::content-type: application/octet-stream
  standard::size: 13
  etag::value: 1295566060
  id::filesystem: smb-share:domain=WORKGROUP,server=192.168.248.6,share=memory_card,user=default
  time::modified: 1295566060
  time::modified-usec: 0
  time::access: 1295566060
  time::access-usec: 0
  time::changed: 1295566060
  time::changed-usec: 0
  unix::device: 232967
  unix::inode: 2029638
  dos::is-archive: TRUE
  metadata::gedit-position: 12
  metadata::gedit-spell-language: en_US
  metadata::icon-scale: 1
  metadata::nautilus-icon-position: 64,582
  metadata::nautilus-icon-position-timestamp: 1295584410

*******************************************************************************

[keith@state ~]$ gvfs-cat smb://WORKGROUP\;default\@192.168.248.6/memory_card/myfile3
Sample file

gvfs-cat: smb://WORKGROUP;default.248.6/memory_card/myfile3: error reading: Permission denied

*******************************************************************************

NOTE: "Sample file" is the actual content of "myfile3."  so gvfs-cat is listing the file THEN reporting permission denied.

*******************************************************************************

> (In reply to comment #2)
> > :ls: cannot open directory keith/.gvfs: Permission denied
> This is correct, we denied access for users other than current one (including
> root).

OK, thanks again. I can access .gvfs when in a shell as user "keith."

Tomáš, your help is much appreciated, I hope this helps you help me.

Sincerely,
Keith Laten Williams

Comment 5 Tomáš Bžatek 2011-01-25 10:31:38 UTC
(In reply to comment #4)
> NOTE: "Sample file" is the actual content of "myfile3."  so gvfs-cat is listing
> the file THEN reporting permission denied.

Oh, this is interesting, so it actually starts reading the file and throws an error at the end. Out of curiosity, could you test larger files than 65534 bytes?

Also, please grab the following samba update to see if it helps: http://koji.fedoraproject.org/koji/buildinfo?buildID=212855

Comment 6 Fedora End Of Life 2012-08-16 21:02:26 UTC
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping


Note You need to log in before you can comment on or make changes to this bug.