Looking for NAS Hardware Recommendations

Tue Jul 12 14:25:27 MST 2011

Joeseph,

One more issue, oh Great Buffalo NAS one....;-)

I started to work on rooting the device by following this
http://buffalo.nas-central.org/wiki/Category:LS-WXL. First stumbling block
is I have firmware 1.43. However, the zip key for 1.41 worked to unzip the
firmware image. It turns out ssh is already enabled for root in 1.43, but
one needs a password. It is not the same as the admin password. So, I set up
an ssh key and put the disk image back together as described in the article.
However, how do I get the LS-WXL beastie to gobble up the new firmware?

The web access only allows firmware to be downloaded from Buffalo (no upload
file dialog, just a button to update the firmware, which only goes to
Buffalo to check on available updates, and then installs them), and the
Windows software does not have an option to upload firmware, either. I can
get in with acp_commander to the shell prompt, which seems to be a disguised
telnet prompt, so I am not sure how to upload new firmware via that method.

Anyway to get the root password from the device or the file system I
downloaded so I can use that to ssh in and not have to replace the firmware?

Thanks for any further suggestions you may have!

Mark

On Mon, Jul 11, 2011 at 7:13 AM, Joseph Sinclair
<plug-discussion at stcaz.net>wrote:

> rsync will preserve ownership if you set the option to do so (I don't
> recall the exact flag offhand).
> I actually prefer rsync over the Samba mount because cifs doesn't
> understand POSIX permissions.
>
> If you root the box you can certainly do the rsync over ssh, but on a local
> net native(uncompressed) rsync protocol is *immensely* faster because the
> little ARM chip in the NAS can't handle the ssh encrypt/decrypt very fast.
>
> SSH is useful for a lot of things, but I prefer the rsync daemon for rsync.
>
> IIRC backuppc can handle the hardlink issue via rsync (rsync can preserve
> hardlinks, softlinks, etc...), but if not then your best bet might be to
> install something more NAS-friendly.
>
> I'd not recommend installing Debian.  It's possible, but the machine is
> quite limited in CPU and RAM, so the experience is likely to be somewhat
> frustrating.  Most of the people who install Debian are running
> Terastations, which have desktop CPU's rather than ARM chips (and cost 5
> times more).
>
> On 07/10/2011 10:42 PM, Mark Phillips wrote:
> > In the shared folders section, one can check Windows, Apple, disk backup,
> > ftp, and sftp. When I clicked Windows and backup, rsync works.
> >
> > mark at orca:~/Desktop$ rsync SANY0002.JPG
> rsync://xxx.xxx.xxx.xxx/array1_fred/
> > mark at orca:~/Desktop$ rsync rsync://xxx.xxx.xxx.xxx/
> > array1_fred
> > mark at orca:~/Desktop$
> >
> > The file was copied to fred, as verified by ftp.
> >
> > Thanks for the link. I am worried that backup files will loose their
> > ownership attributes when I back them up, as the poster says:
> >
> > "Yes, you can use rsync on another machine to connect to the
> rsync-enabled
> > shares on a LSpro; BUT all the files created by this method on the LSpro
> are
> > owned by root/root and not by any of the users created on the LSpro, and
> > there is no way to delete or update these files except by using the rsync
> > command."
> >
> > If I root the device and enable ssh, then I can rsync in via ssh and
> bypass
> > all this Buffalo c**p, right? Backuppc also depends on hard links, so
> > perhaps I have to go all the way and install Debian on the box?
> >
> > Mark
> >
> > On Sun, Jul 10, 2011 at 10:18 PM, Joseph Sinclair <
> plug-discussion at stcaz.net
> >> wrote:
> >
> >> For the mount, you can just use normal mount with -t cifs (or put it in
> >> fstab with cifs as the filesystem type).
> >> umount is generic; the unmount interface standardized a while back,
> that's
> >> why umount.cifs is no longer in Debian, it's obsolete.
> >>
> >> For rsync, the module name will never have a space.  Given that it's not
> >> showing up the way we expect, my best guess is the module naming changed
> in
> >> the most recent revisions of the firmware.
> >> It seems something odd is going on, quite possibly the rsync daemon is
> >> running but no shares are enabled as backup targets.
> >> According to the Linkstation forums on buffalo.nas-central.org, You
> have
> >> to go into the backup section in the web interface and set each share
> that's
> >> supposed to be available via rsync as a backup target (not entirely sure
> >> what that looks like).
> >> Here's the post I found:
> >> http://forum.buffalo.nas-central.org/viewtopic.php?p=41941#p41941
> >> It's not 100% applicable, but it should apply to your device fairly
> >> equally.
> >>
> >>
> >> On 07/10/2011 07:12 PM, Mark Phillips wrote:
> >>> The only way I can gain access to the shares is to use the following. I
> >>> created a new share called 'fred' and deleted the other shares:
> >>>
> >>> mount.cifs   //xxx.xxx.xxx.xxx/fred   /home/nas_share   -o
> user=user_name
> >>> password=pass
> >>>
> >>> Of course, umount.cifs is no longer in Debian, but umount -f works to
> >>> unmount the share.
> >>>
> >>> I cannot get rsync to work. According to the man page the following
> >> should
> >>> return a list of shares:
> >>>
> >>> rsync rsync://xxx.xxx.xxx.xxx/
> >>>
> >>> Nothing is returned (eg a blank line). I tried telnet xxx.xxx.xxx.xxx
> 873
> >>> and I got the rsync response @RSYNCD: 30.0, so the daemon is running, I
> >>> suppose.
> >>>
> >>> The following all return 'unknown module' regardless of what name I put
> >>> after the url (array1_fred, , array0_fred array2_fred)
> >>>
> >>> rsync some_file rsync://xxx.xxx.xxx.xxx/array1_fred/
> >>>
> >>> or a '/' instead of a '_' returns the same error for module array1,
> >> array2,
> >>> array0. I also tried Array[0,1,2] with the same result. Some of the web
> >>> pages show the name as Array 1, so I tried the capital A and a space,
> but
> >>> still not luck.
> >>>
> >>> When I ftp into the box, the path to fred is
> xxx.xxx.xxx.xxx/array1/fred.
> >>>
> >>> I tried restarting the Linkstation, and no change.
> >>>
> >>> I also tried the alternative rsync format, rsync some_file
> >>> xxx.xxx.xxx.xxx::array1_fred, and that did not work.
> >>>
> >>> Any more ideas on how to get rsync to work?
> >>>
> >>> Thanks!
> >>>
> >>> Mark
> >>>
> >>> On Sun, Jul 10, 2011 at 1:15 PM, Joseph Sinclair
> >>> <plug-discussion at stcaz.net>wrote:
> >>>
> >>>> Dash and underscore are fine.
> >>>> The only way to "reset" the name using the standard web interface is
> to
> >>>> delete the share and re-create it with the new name.
> >>>>
> >>>>
> >>>> On 07/10/2011 11:23 AM, Mark Phillips wrote:
> >>>>> Can the share name have a dash or underscore in it? How can I "reset"
> >> the
> >>>>> share names?
> >>>>>
> >>>>> Thanks for all your help!
> >>>>>
> >>>>> Mark
> >>>>> On Jul 10, 2011 10:59 AM, "Joseph Sinclair" <
> plug-discussion at stcaz.net
> >>>
> >>>>> wrote:
> >>>>>> The info folder is used by the web interface; don't delete that
> unless
> >>>>> you'd like to reload the device from scratch ;)
> >>>>>> The correct value should be array1_Hshare. array1_Hshare is the
> rsync
> >>>>> top-level "module" name, not a directory.
> >>>>>>
> >>>>>> The issue you're seeing sounds like a case-match issue or something
> >>>>> similar. The module will be exactly "array1_" followed by the
> (initial)
> >>>> name
> >>>>> of the directory on the array.
> >>>>>> If you initially put spaces in, or changed the name, then you'll
> have
> >> a
> >>>>> hard time figuring out the module name because it's based on the
> first
> >>>> name
> >>>>> you give for the share; it doesn't get updated if you change the
> share
> >>>> name
> >>>>> later.
> >>>>>>
> >>>>>> Also, if you changed the RAID settings, then try using array2 or
> >> array0,
> >>>>> just in case it changed the array numbering.
> >>>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------
> >>>> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
> >>>> To subscribe, unsubscribe, or to change your mail settings:
> >>>> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
> >>>>
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------
> >>> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
> >>> To subscribe, unsubscribe, or to change your mail settings:
> >>> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
> >>
> >>
> >> ---------------------------------------------------
> >> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
> >> To subscribe, unsubscribe, or to change your mail settings:
> >> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
> >>
> >
> >
> >
> > ---------------------------------------------------
> > PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
> > To subscribe, unsubscribe, or to change your mail settings:
> > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.PLUG.phoenix.az.us/pipermail/plug-discuss/attachments/20110712/fdaec701/attachment.html>