Looking for NAS Hardware Recommendations

Wed Jul 13 19:09:09 MST 2011

The best suggestion I can make (other than waiting for acp_commander to get an update so it's able to open up the 1.43 firmware) is to use the Windows or Mac uploader to upload your modified firmware.

On 07/13/2011 05:45 PM, Mark Phillips wrote:
> On Tue, Jul 12, 2011 at 10:38 PM, Joseph Sinclair <plug-discussion at stcaz.net
>> wrote:
> 
>> I missed the 1.43 part...  Seems they've improved security.
>>
>> If you can get a shell prompt with acp_commander, try running whoami. If
>> you're already root, then "passwd -d root" will clear the current password,
>> and you can then set it to anything you like with "passwd"
>>
> 
> I get a shell prompt, but nothing seems to work. Every command returns 3
> blank lines and a prompt.
> 
>>
>> The only safe way to upload firmware is, unfortunately, a Windows or Mac
>> binary that's included with the firmware update.
>>
>> That said, you can try
>> http://buffalo.nas-central.org/wiki/Manually_flash_the_LinkStation%27s_firmwareif you're brave.
>>
> That looks good, but I cannot access /dev/fl1 from the telnet prompt I get.
> Nothing works at that prompt.
> 
>>
>> You might also just try (from an acp_commander shell prompt) copying the
>> ssh key (put it on a share first) from the array locally over to
>> /root/.ssh/authorized_keys (make sure to check permissions after copying),
>> then try ssh.
>>
> 
> Good idea, if I could just get telnet to work. Any thoughts on that?
> 
>>
>> good luck.
>>
>> On 07/12/2011 09:59 PM, Joseph Sinclair wrote:
>>> You shouldn't need to change or upload firmware.
>>>
>>> acp_commander can reset the root password (If it can get a shell prompt
>> it should be able to reset the password...)
>>>   java -jar acp_commander.jar -t $YOUR_NAS_IP_ADDRESS -o
>>> That will clear the root password to nothing, allowing you to login via
>> ssh or telnet as root with the (blank) password.
>>>
>>> You should be able to re-secure things from there (ideally drop an SSH
>> key in for root, create a second account that can sudo and drop a key there
>> as well, then lock the password for both to prevent password login and
>> disable telnet).
>>>
>>> On 07/12/2011 02:25 PM, Mark Phillips wrote:
>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------
>>>> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.PLUG.phoenix.az.us/pipermail/plug-discuss/attachments/20110713/d2766ffe/attachment.pgp>