Quantcast
Channel: WebLog Olivier Berger
Viewing all articles
Browse latest Browse all 32

Using Iomega Home network Disk Drive 500 GB with GNU/Linux (Debian testing)

$
0
0

I have purchased a Iomega Home network hard drive 500 GB, to use it as a NAS.

There have been problems to use it with my GNU/Linux Debian (testing) desktop, but I think I now can have a working setup, even if it's a bit of a hack.

The following informations were posted initially to http://www.iomegasupportforums.com/phpbb2/viewtopic.php?p=33985#33985 for the curious ones.

First I should say I upgraded the firmware (now I have K104.W11).

To check if the drive is accessible through SMB/CIFS :

# findsmb

                                *=DMB
                                +=LMB
IP ADDR         NETBIOS NAME     WORKGROUP/OS/VERSION
-
192.168.0.15    STORAGE-3806   [WORKGROUP] [] []

... at least on my network, it's like that (you may not have the same output... it changed after I installed the most recent FW)

Now, to try and see the shares (here, I have a PUBLIC dir exported via SMB) :

# smbclient -N -L '//STORAGE-3806'
Domain=[WORKGROUP] OS=[] Server=[]

   Sharename       Type      Comment
   -       ---
   PUBLIC          Disk     
   IPC$            IPC       
Domain=[WORKGROUP] OS=[] Server=[]

   Server               Comment
   -            ---

   Workgroup            Master
   -            ---

Note that the -N flag is to disable password prompt for smbclient.

Attention : "Weak authentication" may be disabled for SMB clients in your Distro... as it is on mine (Debian testing).

So if you try the following command (or alike) and get an error with authentication, then there may be something to try.

Symptom :

# smbclient  -W WORKGROUP '//STORAGE-3806/PUBLIC'
Password:
Domain=[WORKGROUP] OS=[] Server=[]
Server requested LANMAN password (share-level security) but 'client use lanman auth' is disabled
tree connect failed: SUCCESS - 0

Workaround : So try copying /etc/samba/smb.conf (or similar, I'm on Debian) to for example /root/iomega-smb.conf, and add, in the [global] section these two lines (or changing existing lines) :

client plaintext auth = yes
client lanman auth = yes
client ntlmv2 auth = no

EDIT : client ntlmv2 auth = no seems necessary now too

Now smbclient -s iomega-smb.conf -W WORKGROUP '//STORAGE-3806/PUBLIC' will accept your password.

Also, as I've struggled with trying to access the drive in Nautilus using smb:// URI.

It wouldn't work on my Debian system since "weak" authentication was disabled in the samba default configuration file.

I've found a way to access it anyway : You first have to create a file named ~/.smb/smb.conf.append, and add the following inside it :

[global]

client plaintext auth = yes
client lanman auth = yes

Then you will be able to access it through URI like : smb://WORKGROUP:guest:xxxx@192.168.0.2/PUBLIC in Nautilus (assuming you put your password instead of the xxxx) or smb://WORKGROUP:guest@192.168.0.2/PUBLIC, and answer the password prompt (which will be stored in the gnome keyring).

Cool... my NAS is usable at last.

Update 2008/04/13 :

I have tried to use it with a CIFS mounted filesystem on my desktop, and experienced a kernel oops with kernel 2.6.24 (Debian testing)... so had to revert back to 2.6.22 to be able to mount it. More details in Debian bug #463402.

Update 2008/05/24 :

Thanks to Daniel (see comments bellow), I have succesfully tried to use a FUSE-based mount tool named smbnetfs which helps mount the drive's shares in the filesystem (in userland) so that ordinary commands work. And being based on libsmb (like with Nautilus), it doesn't crash like the CIFS kernel driver. Note that you need to enable the ~/.smb/smb.conf.append settings (see above), and then you can mount a share by simply using (for instance):

$ mkdir ~/smb
$ smbnetfs ~/smb

And then you can access the drive's contents with something like :

$ ls ~/smb/myuser:mypassword@192.168.0.2/PUBLIC/

Cute ! Now, let's see if it's stable and fast enough for making backups over it.

Update 2009/0302 : The CIFS bug has been fixed upstream (Kernel bug #10451) and the patch applies allright to Debian stable's kernel (more details at Debian bug #463402). No more kernel oops, now ! Cool. Will try to test perfs.


Viewing all articles
Browse latest Browse all 32

Latest Images



Latest Images