Nautilus fails to browse any share on network to which Iomega Home Network Hard Drive (MDHD500-N, firmware K108.W15) is attached.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
samba (Ubuntu) |
Fix Released
|
Low
|
Unassigned |
Bug Description
Binary package hint: gvfs
Nautilus fails to browse any share on network to which Iomega Home Network Hard Drive (MDHD500-N, firmware K108.W15) is attached.
Might be 209520 or 296673 - but this should make diagnosis easier.
Reproduced bug using Ubuntu i386 distribution disks for 7.10, 8.04, 8.04.2, 8.10 and 9.04 beta - in other word, standard Ubuntu configuration. The Iomega NAS had immediately prior had a firmware upgrade with subsequent hard reset. This should be reproducible by maintainers.
The Iomega server is SAMBA or SAMBA-like, with a rudimentary html interface. It is normal for end users to not have control over all server settings in many situations, so this is still a gvfs bug.
As with similar bugs, all SAMBA shares are reported correctly with findsmb and smbclient, and can be mounted using smb4k.
Sebastien Bacher (seb128) wrote : | #1 |
Changed in gvfs (Ubuntu): | |
assignee: | nobody → desktop-bugs |
importance: | Undecided → Low |
status: | New → Incomplete |
Stephen D Kamm (s-kamm) wrote : | #2 |
Yes this bug is reproducible, which I had attempted to make that clear in the original bug report. The following is more explicit.
This bug occurs when Ubuntu is being run live from an i386 distribution CD: 7.10, 8.04, 8.04.2, 8.10, or 9.04 beta - the kind one burns from the isos available here: http://
To reproduce this bug, you will also need the following:
-An i386-type vanilla box with an optical drive and an ethernet port, fully capable of running the Ubuntu distribution CD referenced above.
-A vanilla router - I use a Linksys WRT54G. My router is also connected to the internet through PPPoE to a DSL modem.
-An Iomega "Home Network Hard Drive" (MDHD500-N), running firmware K108.W15. Iomega advertises this as supporting Debian 3.0. Have the Gnome developers written code which is not backwards compatible with this hardware?
-Two ethernet cables.
Connect your vanilla i386 computer and Iomega NAS to the router, each with its own ethernet cable. Feel free to hard-reset the Iomega NAS, to remove any configuration questions. Reboot the computer using the live Ubuntu disk - be sure the optical drive has a high priority in the BIOS boot order. Attempt to browse to the "PUBLIC" share of the Iomega NAS using Nautilus; you won't find it. However, "findsmb" and "smbclient -L 192.168.1.xxx" do find it.
There's your bug.
A computer running Windows Explorer in Windows XP would find the Iomega share(s). Further experimentation will show that the Iomega drive effectively shileds itself and all other SAMBA shares on the network from Nautilus browsing. The full configuration of the Iomega NAS is not available to the end user, but that would actually be the typical situation for most end users on networks. Nautilus browsing of the network apparently yields a stream of similar bugs. I contend that I have outlined a simple experiment that is universally reproducible by Gnome maintainers, an experiment that should solve many bugs in that stream.
Sebastien Bacher (seb128) wrote : | #3 |
how do you try to browse the drive? using the network location in nautilus or the url directly? in what workgroup is it? does smbtree browse it correctly, could you copy the log there?
Stephen D Kamm (s-kamm) wrote : | #4 |
Stephen D Kamm (s-kamm) wrote : | #5 |
- attach002.png Edit (9.1 KiB, image/png)
... then clicking on any share produces attach002.png
(This drive has had a firmware upgrade and hardware reset immediately before answering your questions, which apparently does not delete drive contents.)
Stephen D Kamm (s-kamm) wrote : | #6 |
Having been just reset, workgroup=
====
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
ubuntu@ubuntu:~$ findsmb
IP ADDR NETBIOS NAME WORKGROUP/
-------
192.168.1.104 STORAGE-36AE [WORKGROUP] [R] [R]
ubuntu@ubuntu:~$
ubuntu@ubuntu:~$
ubuntu@ubuntu:~$ smbclient -L 192.168.1.104
Enter ubuntu's password:
Domain=[WORKGROUP] OS=[R] Server=[R]
Sharename Type Comment
--------- ---- -------
PUBLIC Disk
Betsey_Net Disk
Stephen_Net Disk
linux-backup Disk
IPC$ IPC
Domain=[WORKGROUP] OS=[R] Server=[R]
Server Comment
--------- -------
Workgroup Master
--------- -------
ubuntu@ubuntu:~$
ubuntu@ubuntu:~$
ubuntu@ubuntu:~$ smbtree
Password:
ubuntu@ubuntu:~$
Stephen D Kamm (s-kamm) wrote : | #7 |
If you're looking for a specific log I have yet to produce, please point to it.
These results were produced with a live session of Ubuntu 9.04 beta desktop i386. I intend to proceed with a work-around on my installations, so the Iomega NAS will no longer be in its hard-reset state. I am willing to follow further instructions using a boot from a live session disk, however. Let me know if you prefer an earlier version.
sdk
Sebastien Bacher (seb128) wrote : | #8 |
reassigning to samba since the samba tools don't browse the share either so it's rather an issue there
affects: | gvfs (Ubuntu) → samba (Ubuntu) |
Changed in gvfs (Ubuntu): | |
assignee: | desktop-bugs → nobody |
Changed in samba (Ubuntu): | |
status: | Incomplete → New |
Stephen D Kamm (s-kamm) wrote : | #9 |
Just want to make sure it's understood that smbtree doesn't browse the share when run under specific conditions outlined above - particularly the fact that it was in a live CD session. Under my current, evolving (implementing work-arounds) configuration, smbtree does produce output, listed below.
Are there "bad" interactions among multiple SAMBA servers that cannot be isolated to configuration of single server? Given that many network devices use embedded SAMBA servers, shouldn't Nautilus, hence gvfs, be extremely robust in browsing and mounting shares?
I post the following (from current, not-controlled-
===
stephen@
IP ADDR NETBIOS NAME WORKGROUP/
-------
192.168.1.66 IOMEGA-36AE [UTOPIA_BEACH] [R] [R]
192.168.1.100 INSPIRON-UBUNTU [UTOPIA_BEACH] [Unix] [Samba 3.2.3]
192.168.1.102 UBUNTU-810 +[UTOPIA_BEACH] [Unix] [Samba 3.2.3]
stephen@
Enter stephen's password:
Domain=
Server requested LANMAN password (share-level security) but 'client lanman auth' is disabled
tree connect failed: SUCCESS - 0
stephen@
Password:
UTOPIA_BEACH
\\UBUNTU-810 Samba 3.2.3
\\UBUNTU-
\\UBUNTU-810\IPC$ IPC Service (Samba 3.2.3)
\\UBUNTU-
\\UBUNTU-
\\UBUNTU-
\\UBUNTU-
\\UBUNTU-
\\IOMEGA-36AE
Server requested LANMAN password (share-level security) but 'client lanman auth' is disabled
failed tcon_X with NT_STATUS_OK
\\INSPIRON-UBUNTU Inspiron-Ubuntu server (Samba, Ubuntu)
\\INSPIRON-
\\INSPIRON-
\\INSPIRON-
stephen@
Sebastien Bacher (seb128) wrote : | #10 |
ok, that bug is just confusing, can you describe clearly:
- the machines on your network
- which one you are using
- what you try to do and what error you get
- if the samba command line tools work better
- what you changed and why
Stephen D Kamm (s-kamm) wrote : | #11 |
Whoa - stop!
Comment 9 does not describe Bug 354243 directly, but rather, a related situation. That's what all those words I typed into Comment 9 mean. I had hoped the the additional information would be helpful. I'm sorry it wasn't.
I opened Bug 354243 specifically because of the "confusion" evident in Bug 209520. But the gist of both bugs is this: There is something wrong with Nautilus and/or its dependencies - recent versions of Nautilus are not robust in browsing network shares.
I intended, in Bug 354243, to offer a reproducible demonstration of this failure. Comments 1 and 4 outline that demonstration, but again:
The network in Bug 354243 is a vanilla router; a vanilla computer; an Iomega MDHD500-N network hard drive, running firmware K1.08 L1.0 W1.5; and an Ubuntu 9.04 beta desktop i386 CD, running in LIVE SESSION.
(Sorry to shout, but last is important: live session eliminates user error in configuration, and, more important, live session is supposed to demonstrate Ubuntu's capabilities with a wide variety of hardware.)
And I will anticipate the objection that this is an Iomega problem: Windows finds the Iomega NAS; smbclient finds it; smb4k even mounts it - it's not trying to hide itself. The Iomega NAS is just one among many "black-box" embedded SAMBA servers that a robust, desktop-ready file manager needs to be able to browse. Current Nautilus fails.
Sebastien Bacher (seb128) wrote : | #12 |
it's not so complicate to have a clear description specify:
- the version of ubuntu you are using
- the actions you are doing
- what happens and what else you would expect
in this case extra informations:
- what server type do you try to contact
- can you contact it using samba command line commands
Sebastien Bacher (seb128) wrote : | #13 |
I'm trying to make a sense of all the comments there
is "IOMEGA-36AE" the drive you try to connect?
is the issue
"$ smbclient -L 192.168.1.66
Enter stephen's password:
Domain=
Server requested LANMAN password (share-level security) but 'client lanman auth' is disabled
tree connect failed: SUCCESS - 0"
which shows that command line tools can't connect to it either?
if that's the case the issue is clear, the server expect lanman authentification which is disabled nowadays in samba by default for security reasons, I will let the samba guys comment on how to best process from there to get a working configuration if that's the issue
Thierry Carrez (ttx) wrote : | #14 |
Hm. If you read comment 6 it appears that smbclient successfully browses the share ?
Comment 9 is confusing. Just to be sure, try put the following in your /etc/smb.conf to force samba client tools to use it:
client lanman auth = yes
And let us know if it fixes your browsing issue.
Changed in samba (Ubuntu): | |
status: | New → Incomplete |
Thierry Carrez (ttx) wrote : | #15 |
Above should read "/etc/samba/
Stephen D Kamm (s-kamm) wrote : | #16 |
Given the confusion introduced by my Comment 9, I will restrict my further comments to the original case of Bug 354243: a LIVE SESSION run from a "Ubuntu 9.04 beta Desktop i386" CD.
That being the case, I ask: Once I have edited and saved /etc/samba/
===
Also, does the case I present show that the underlying problem, of which https:/
Thierry Carrez (ttx) wrote : | #17 |
OK, let's sum up this bug (please confirm I got it right):
- You boot a Jaunty beta LiveCD
- Running "smbclient -L <NASBOXIPADDRESS>" successfully lists the shares on NAS box
- Running "findsmb" successfully shows NAS box
- Opening Places/Network in Nautilus you can see the NAS box
- Double-Clicking on the NAS box in Nautilus fails to list the shares, error is "Failed to retrieve share list from server"
Here are a few more tests/confirmat
- What does running "smbtree -N" return ?
- When you double-click on "Windows Network" and drill down to your NAS box, does double-clicking on it list the shares ?
- Does anything change if you put "client lanman auth = yes" in /etc/samba/
===
I don't see the relation between this bug and bug 264943, which was a gvfs crash ?
Stephen D Kamm (s-kamm) wrote : | #18 |
- Screen001.png Edit (746.8 KiB, image/png)
Thank you for addressing the specific case I have set up. In answer to your first five assumptions, "YES" except I failed to recreate the browser result shown in the attachment to Comment 4. Now, the NAS shares do not show, only "Windows Network". Double-clicking on "Windows Network" yields "Failed to retrieve share list from server".
See attachment for complete illustration.
The following are or may be different from Comment 4:
- The NAS was not hard-reset immediately prior to latest experiment.
- I have given the NAS a static IP address.
- I am not sure of the power-up order for the computer, router, and NAS. From now on, I will leave the NAS and router on while re-booting the computer. I hope we can solve the now slightly revised bug under these conditions, because it allows undisrupted use of the NAS from Windows, and fstab-mounted Ubuntu, in between experiments.
Stephen D Kamm (s-kamm) wrote : | #19 |
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
ubuntu@ubuntu:~$ smbtree -N
ubuntu@ubuntu:~$
Stephen D Kamm (s-kamm) wrote : | #20 |
- Screen003.png Edit (683.9 KiB, image/png)
I was able to "sudo gedit /etc/samba/
Stephen D Kamm (s-kamm) wrote : | #21 |
Addendum to Comment 18:
Other differences from previous trial, along with setting static IP address on the NAS, I set host name to "IOMEGA-36AE" (was "STORAGE-36AE") and domain name to "UTOPIA_BEACH" (was "WORKGROUP"). I'm going to guess that when the domain names match, the shares are displayed at the same level as "Windows Network".
I don't think this was the problem, however.
Thierry Carrez (ttx) wrote : | #22 |
OK, summing it up (again):
- You boot a Jaunty beta LiveCD
- Running "smbclient -L <NASBOXIPADDRESS>" successfully lists the shares on NAS box
- Running "findsmb" successfully shows NAS box
- Running "smbtree -N" doesn't list the NAS box
- Double-Clicking on "Windows network" in Nautilus Places/Network brings a "Unable to mount location / Failed to retrieve share list from server" error box.
My guess is that your NAS box doesn't properly implement the local master browser for the windows networking domain. Clicking 'Windows Network' or running "smbtree -N" query the local master browser. Please test:
- Run "smbtree -b -N"
- Open location "smb://
Stephen D Kamm (s-kamm) wrote : | #23 |
- Screenshot.png Edit (904.3 KiB, image/png)
Thank you. I confirm your summary.
"smbtree -b -N" returns no output
Opening the location as specified creates browse-able locations in Nautilus, and mounts them on the Desktop. This is somewhat easier (in my situation) than using the command line or modifying fstab. I will test this in my "real-life" home network.
Shouldn't the operation of obtaining the NAS's IP address, as with findsmb, and passing it to the browsing function be written into Nautilus? It seems to me that it advances Ubuntu to have it "just work" with cheap, widely-available hardware.
Stephen D Kamm (s-kamm) wrote : | #24 |
Bad news in "real-life" network (not the controlled experiment in bug report):
Running Intrepid, desktop and laptop on network, each with own Samba server (i.e. three total, including NAS), Nautilus Location>
CLI and fstab mounting works.
Essentially, Iomega NAS kills default Nautilus network browsing for any user on the network.
Thierry Carrez (ttx) wrote : | #25 |
Apparently you are not the only one experiencing problems to interact with that specific kind of NAS box.
See
http://
or
http://
Could you look up the various tricks described there and let us know if it improves the situation.
Braam Wijsmuller (stratofarmer) wrote : | #26 |
I've recently crawled back out from under my rock and discovered that the issue has been solved for me!
I was experiencing the exact same problems with my Iomega Home Network Hard Drive (MDHD500-N, firmware K1.08 L1.0 W1.5) and Ubuntu Gutsy or/and Intrepid.
After having upgraded to Jaunty (final) the issue is solved. I can mount and browse the shares on the network disk using Nautilus without any problems.
Cheers!
Stephen D Kamm (s-kamm) wrote : | #27 |
Thank you Thierry and Braam.
Thierry, I didn't try all the tricks you linked to above, some were speculative or more difficult than the CLI or fstab mount work-around. The earlier version of the Iomega firmware did not work for me.
Braam, I confirm your good result with an installed version of 9.04, with this exception: if the network also contains a computer running 8.10, Nautilus still fails to browse the NAS. I will soon upgrade the other computer.
Thanks again.
Thierry Carrez (ttx) wrote : | #28 |
OK, then we'll assume it got fixed in Jaunty... Thanks for the followup !
Changed in samba (Ubuntu): | |
status: | Incomplete → Fix Released |
Thank you for taking the time to report this bug and helping to make Ubuntu better. Please answer these questions:
* Is this reproducible?
* If so, what specific steps should we take to recreate this bug?
* What error do you get exactly?
This will help us to find and resolve the problem.