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 > 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@orca:~/Desktop$ rsync SANY0002.JPG >> rsync://xxx.xxx.xxx.xxx/array1_fred/ >>> mark@orca:~/Desktop$ rsync rsync://xxx.xxx.xxx.xxx/ >>> array1_fred >>> mark@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@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 >>>>> 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@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@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@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@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@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@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@lists.plug.phoenix.az.us > To subscribe, unsubscribe, or to change your mail settings: > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss