Connecting Network Attached Storage (NAS) to a WinXP Guest in VMware: FAIL

I had two desktop computers running Ubuntu 10.04.  On one of them, I was running VMware Workstation 7.1, with Windows XP SP3 as a guest operating system in a virtual machine (VM).  I had just figured out how to network these two computers using Samba shares within a home network, where the two computers were connected via ethernet cables to a shared router.

Now there was a new question.  Could I add a Synology DS109 network-attached storage (NAS) device (essentially an external hard drive enclosure designed for network backup and file serving) to this network?  Of course I could, in the sense of running an ethernet cable from the Synology to the router; but what I was wondering was whether I could make this work despite the fact that the software for the Synology was available only for Windows and Mac, and not Linux.

It was a question, in other words, of whether I could run the Synology software in Windows XP in a guest VM.  I gave it a whirl.  I ran the Synology installation CD and went through the steps to set up the Synology Server.  This opened the Synology Assistant, a setup wizard; and after a moment, it gave me an error message:

No Synology Server was found on the local network.  Please make sure:

1.  Synology Assistant is not blocked by the firewall of your computer OS or anti-virus applications.

2.  Synology Server and your computer are both connected to the network.

3.  You have switched on the power of Synology Server.

Option 1 was the only one that seemed to explain the situation.  I decided to back up and make sure that I could see a shared folder on the other computer from within Windows.  In my first try, I set up that shared folder on an NTFS partition, and that led to a separate investigation of the difficulties of sharing an NTFS partition in Ubuntu.

That wound up taking longer than expected, so in the meantime I just focused on the link between the Synology and the computer in which I had VMware running.  I noticed that, in Ubuntu's Places > Network, it listed three items:  ANTEC (the name of this computer), Windows Network, and WINXP8 (the name of the computer running in the WinXP VM).  Plainly, Ubuntu was seeing Windows.  Was Windows seeing Ubuntu?  Or did it need to?  A first answer was that, of course, you could go into Windows Explorer > Tools > Map Network Drive and (assuming you had VM > Settings > Options tab > Shared Folders set up) you could gain access to NTFS and ext3 partitions outside of the drive C that existed inside the virtual machine.  These drives would be visible in Windows Explorer > My Network Places > Entire Network > VMware Shared Folders.

I tried running the Synology setup wizard again.  It gave me the same error as before.  I did a search and found webpages describing how to use NAS freeware to use another computer as an NAS device.  This raised two thoughts.  First, possibly I could use some software other than Synology's CD to make contact with the NAS device.  Second, perhaps I should consider using another computer myself, in lieu of the Synology unit.  I decided to go ahead with the Synology project for now; I could return or sell the device if it really wasn't what I wanted.  I probably could have assembled another computer at equal or lower cost, with far greater potential storage capacity, with more RAID options, with a more powerful processor (for e.g., checksum calculations) if needed, with what might prove to be more options in the choice of software packages and commands to manage and adjust it, and with more flexible hardware troubleshooting options (i.e., more than just fix it or replace it) in the event of malfunction.  Its drawbacks would include time and expense for software and hardware selection, learning, installation, maintenance, and troubleshooting; physical space requirements; power consumption; and noise and heat generation.

For the time being, I searched Synology's website and found a post raising the thought that perhaps a Windows connection was crucial only for the initial setup of the Synology device.  So I rebooted the computer into Windows XP instead of Ubuntu and ran the Synology setup CD from there.  This time, the wizard found the DiskStation right away.  So, really, I probably could have set the thing up using my laptop.  It seemed to be just a matter of connecting a Windows-based computer to configure the hard drive that I had inserted into the NAS unit.

Following the Quick Installation Guide, I looked for a Browse option in the Synology Assistant, but didn't see one.  Instead, in the Management tab of the Assistant, I double-clicked on the DiskStation entry, and that seemed to be the correct thing to do:  it opened a different Setup Wizard, or maybe a continuation of the same one.  The wizard said, "Please input the path of installation file."  Maybe this was where I was supposed to browse to the .pat file?  Sure enough. Browse brought up four different .pat files.  I chose the one for the 109 and opted for One-Click Setup.  It warned me that all data in the hard drive would be deleted.  I hoped it meant the hard drive that I had inserted into the NAS unit.  Lights began flashing on the unit.  It went through several steps:  Apply network settings, Format hard drive, Install DSM (DiskStation Manager) to hard drive, and Write configurations.  For my 2GB drive, the whole process took about 20 minutes.

When it was done, it said, "System has been installed successfully."  Then it just sat there.  Now what?  The other programs on the CD's Installation Menu were Data Replicator, in case I wanted to use the unit for backup rather than as a file server, and Download Redirector, for some purpose I didn't fully understand.  For lack of any better ideas, I rebooted into Ubuntu > Places > Network.  The list of places was the same as before.  I tried another search of the Synology website.  The product page for the DS109 definitely said that the unit was "designed for data storage and sharing among Windows, Mac, and Linux."  But how?

I knew I was desperate when I thought that perhaps I should consult the User's Guide.  But then -- what's this?  When I went to the downloads website, I saw that Synology Assistant was also available for Linux!  I had no idea.  I downloaded that and, while I was at it, also snagged what appeared to be a more recent DSM patch (.pat) file.  The User's Guide on the CD was for DSM 2.3, but the one online was for DSM 3.0, so I copied that too.  Apparently DSM was the firmware updater.  The included instructions were incorrect, as I eventually figured out.  All I had to do was to navigate to the folder where I had put the downloaded .tar.gz file ("cd /LOCAL/Synology") and the accompanying install.sh file, type "install.sh," designate /usr/local as the target directory, watch a bunch of error messages roll by, accept its offer to try again by sudo, copy and paste the command it offered to create a symbolic link, and then type "SynologyAssistant."

With that, Synology Assistant was up and running, and it found the DiskStation.  I double-clicked on it.  It opened a webpage in Firefox.  Having used the One-Click installation previously, I knew there was no administrator password, so I just clicked right on in.  Now I was looking at Management and Online Resources icons.  Management gave me all kinds of options.  I noticed I was in DiskStation Manager 2.3; did this mean that there was no DSM 3.0 for Linux?  On the left side, under System, I clicked on DSM Update.  Ah, of course.  This was the part where I got to Browse to the new .pat file I had downloaded.  It said, "Transferring data to the server.  Please wait."  This time, it was done in under 10 minutes.  It then confronted me with a signin screen.  I could not just click on through; it demanded that I enter something.  I tried Administrator without a password.  No go.  I tried my normal Ubuntu login.  Aha! . . . er, no.  That wasn't it either.  The hell.  I was locked out of my own NAS.  I wasn't alone.  Several other people had experienced this just within the last few days.  I suspected it was due to some quirk in newly released software.  I posted a "me too" note on it in Synology's moderated forum and waited.

But then -- reverting again, desperately, to the manual -- I noticed I was supposed to log in as "admin" with no password.  That worked, and now I was in DiskStation Manager 3.0.  I clicked on "Set up a volume and create a shared folder."  That opened Storage Manager.  I selected Storage > Create and that put me in Volume Creation Wizard.  The only option that wasn't greyed out was ISCSI LUN.  The manual didn't define that term, but Wikipedia said it was short for Internet SCSI, where SCSI is short for Small Computer System Interface.  The idea seemed to be that you were using the Internet instead of cables to create a SCSI setup.  LUN was short for "logical unit number."  An ISCSI LUN was apparently just any one of a set of drives in a SCSI array.  In other words, I was creating a logical drive.  So I went with that.

That gave me a choice of some more properties.  One was Thin Provisioning (default = yes), which was said to increase efficiency.  I was supposed to say how much of my 2TB (actually, 1829GB available, according to the dialog) I wanted to allocate to this first volume (default name:  LUN-1).  I was going to be backing up this file server to a 2TB drive, so I didn't worry about splitting the volume to a size that would match the external drive.  I thought it might be a good idea to have more than one volume, in case one went bad or needed maintenance.  The manual said that, on my unit, I could have up to ten.  I looked at my data and decided to go with three volumes of 600GB each.  (This would be changing later.)  Finally, there was an iSCSI Target Mapping option.  Again, the manual didn't explain this.  I found a website that sort of halfway did.  Eventually I just decided to go with the default, which was no, thank you.  I clicked Next > Apply and, in a few seconds, it was done.  I repeated for the other volumes -- or, I guess, LUNs, not volumes.  Then I clicked on the icons this process had created.  Each indicated that it had a 600GB capacity, but none of them actually seemed to have taken a bite out of the 1.8TB total.  Apparently that was how Thin Provisioning worked.  Then, to finish up with Storage Manager, I went to the HDD Management tab > Cache Management > Enable Write Cache.  I also ran a quick S.M.A.R.T. test.

This was all very nice, but I wasn't sure what it was actually accomplishing.  There weren't any new partitions appearing in Nautilus.  I wasn't sure if there were supposed to be.  I bailed out of Storage Manager.  I was looking again at Quick Start.  It said that now I needed to create a shared folder in the Synology.  I followed its link.  It put me into Control Panel - Shared Folder.  I clicked on Create.  In Create New Shared Folder, I set up a folder for LUNDATA, the first of my three LUNs.  It wouldn't let me select "Mount automatically on startup."  I gave both admin and guest read/write privileges for now.  I did the same with the other two LUNs.  I was confused, though:  after completing that step, I still didn't have anything to show for it.

It seemed that Chapter 7 of the User's Guide was where I wanted to be.  It told me to go to Main Menu (i.e., the down-arrow icon) > Control Panel > Win/Mac/NFS if I wanted to enable file sharing.  But that gave me an error:  "You are not authorized to use this service."  So, oops, that meant I had gotten logged out for dillydallying.  (First of many times!)  After re-login, the Quick Start reminded me that next on the list was "Create a User and assign privileges."  It had admin as the system default user already.  I selected that one and clicked edit.  Spooky thing here:  admin did have a password.  I wasn't sure why I didn't have to enter it when logging in.  I wasn't allowed to change the name of admin or disable that account.  I decided to change the password to something that I would actually know.  Admin already had full read/write privileges to my three LUNs.  The guest account was disabled.  I left it that way.  The manual (p. 66) said that each user could also have his/her/its own "home" folder.  It was something I had to enable if I wanted it.  I didn't need it, so I skipped that.

So now I went back to Win/Mac/NFS.  The User's Guide (p. 59) said that the unit supported file sharing in Linux in SMB, FTP, NFS, and WebDAV.  I unclicked the boxes so that the Synology would not offer Windows or Mac file service, which I did not need (and did not intend to provide to anyone else).  Instead, I clicked the Enable NFS box which, the manual (p. 61) said, was for Linux clients.  I figured that, in my Windows XP virtual machine, I would access the folders or LUNs on the Synology as network drives, just as if they had been ext3 drives inside the computer.

The remaining tab in this part of Control Panel had to do with Domain/Workgroup.  I didn't know if I wanted or needed to have the Synology be part of a domain, a workgroup, or both.  But then I found that the Domain/Workgroup tab was greyed out.  As I might have assumed, "workgroup" and "domain" appeared to be Microsoft-specific.  If I went back and enabled Windows file service, the Domain/Workgroup tab became ungreyed.  So that explained that:  it wasn't something I needed in Ubuntu.

In the Control Panel > Groups section of the Synology DSM, I saw that the default "users" group had read/write privileges only to the public folder, which I had disabled.  It was just me, so I didn't need a group.  So I left that all as it was.  Next, in Control Panel > Application Privileges, it appeared I could give users access to specific Synology applications (FTP, WebDAV, File Station, Audio Station, Download Station, or Surveillance Station).  Admin wasn't listed.  I assumed it didn't need to be.  I had no other users, so I skipped that part too.

Chapter 3 in the User's Guide, "Modify System Settings," told me that in Control Panel > Network, I could choose among several types of networks.  In my version of the Network dialog, those options were LAN, PPPoE, Wireless Network, and Tunnel.  The choice for my purposes seemed to be between LAN and PPPoE.  The manual said that I should use PPPoE if I used a cable or DSL modem and if my ISP used PPPoE.  I didn't know how to check that.  It didn't sound familiar, so I decided to start with LAN, the default (first) tab.  It gave me an option of manual or automatic configuration; I chose automatic (which was, again, the default).  That seemed to be about all I could do there.  While I was in the neighborhood, I went to Control Panel > Time and set it to synchronize itself with an NTP server.  

Now it was time to set up shared folders (User's Guide, p. 69).  In Control Panel > Shared Folder, I saw the three LUNs I had set up.  So apparently a LUN was a shared folder.  I had already taken care of this.  But that raised some questions.  If it was shared, what more did I need to do so that the computer would see it?  Should I have set up a "target" when I was creating the LUNs?  And did I want to encrypt them?

If I clicked on the Encrypt box, the "Mount automatically on startup" option became ungrayed.  I would want to enable that option.  But I had to think about that for a minute.  It seemed that encryption would protect the contents of the Synology in case of theft or loss of the physical device.  But apparently it would not protect those contents while the computer was turned on.  Anyone who could get into my computer, either physically or via the Internet, would have access to those contents.  I wasn't presently requiring myself to enter a login ID when I turned on the computer, so anyone sitting in my position would still have access, despite encryption.  I hadn't yet reviewed the part of the manual having to do with Internet access to the Synology, but evidently I would also have the option of logging in to it from elsewhere.  On the other hand, I had once had the experience of not being able to get into a backup that I had encrypted.  I wasn't sure if I had mis-recorded the password or if the encryption system on that backup had somehow gotten corrupted.  On balance, I decided that it would probably be a good idea to password the Internet-accessible data on the Synology, and to start requiring myself to enter a password to log in on the computer (System > Administration > Users and Groups).  But then, when I entered the password for the Synology and clicked OK, I got a warning telling me, "The performance of the encrypted shared folder will be decreased" and "The encrypted shared folder will not be available via NFS."  That would have defeated the purpose of having the Synology.  So I backed out of that.  No hard drive encryption in the Synology.

Well, the Synology was still not showing up in Nautilus.  I searched the manual for "target," in case that was the missing ingredient.  The User's Guide (p. 41) explained, "An iSCSI Target is like a connection interface . . . . [A]ll the LUNs mapped to the iSCSI Target are virtually attached to the client's operation [sic] system."  So apparently I would map my three LUNs to a target, and Ubuntu would see the target.  As the manual advised, I went into Synology's Storage Manager > iSCSI Target > Create.  There was an option to enable CHAP authentication, where the server would verify the client's identity.  I went with that.  I didn't go further and enable two-way authentication; I didn't need the computer to verify that it was contacting the right NAS unit.  I mapped all three LUNs to a single target.

In Edit > Advanced, I had an option to have it calculate CRC checksums for header and data digests.  The purpose would be to reduce or prevent data corruption.  The calculation would burden the CPU in the NAS, but I suspected the cabling would be more of a bottleneck than the processor nonetheless.  One post said that CRC might be a good idea for data traveling through a router, as would be the case here.  A year-old VMware webpage pertaining to a different VMware product (ESX) said that data digest for iSCSI was not supported on Windows VMs.  I decided to start out with these checksum items turned on, and see what the performance was like.  I also had options pertaining to maximum receive and send segment bytes.  The manual didn't seem to have anything on that, and nothing popped out in several different Google searches.  I decided to leave those at their default values of 262144 and 4096, respectively.

I still didn't see the Synology in Nautilus, but now (as I viewed p. 72 of the manual) I believed that was probably because I had not enabled my own username (ray) to have access.  In Synology's Control Panel > User, I added that username and gave myself full read/write access to the LUNs.  But then, whoa, on the next page, the User's Guide said that, to allow a Linux client to access a shared folder, I would have to go into Control Panel > Shared Folders > select the folder > NFS Privileges > Create and set up an NFS rule.  The first box there called for Hostname or IP.  It looked like the best way to identify the client would be by its IP address.  What was the IP address of my Ubuntu computer?  Zetsumei said I should type "/sbin/ifconfig" in Terminal.  I did that and got a bunch of information regarding eth0, lo, vmnet1, and vmnet8.  Same thing if I just typed "ifconfig -a."  A search didn't shed any light.  The number for eth0 came first and looked most familiar, so I tried that, with no mapping and asynchronous enabled.  This still didn't produce anything in Nautilus, so I thought probably I should have mapped.  But to what?  The only options were "Map to admin" or "Map to guest."  How about "Map to ray"?

A search of the Synology website led to a thread that yielded more questions than answers.  For the first time, the thought crossed my mind that the quality of the Synology organization was possibly not as gold-plated as I had hoped or imagined.  Surely the manual could have been clearer; surely, at these prices, the people posting these questions deserved some enlightenment.  At any rate, links in that thread led to one of those multiyear Ubuntu discussions, this one dealing particularly with NFS.  It seemed I should focus on learning about NFS; among other things, some posters felt that it was far better than Samba for sharing files and folders.

So I did a search and found a recent webpage promising to show me how to set up NFS.  I guessed that the real problem might be on the client side, so I started with that part of the webpage.  First off, they wanted me to install some packages:  portmap, nfs-common, and autofs.  A check of Synaptic told me that Synology had not installed these.  After installing them, I looked in the manual for the Synology IP address.  On page 161 (after many references to the IP address), the manual said that I could find it in Main Menu > System Information -- not, that is, in Control Panel.  The IP address it gave was, however, the same as the default entry it showed in Control Panel > Network > Use manual configuration; it was not the number shown in the DNS Server box.  So in the client, following the instructions on that webpage about NFS, I typed "sudo gedit /etc/hosts.deny" and added a line that said "portmap : ALL."  Then I typed "sudo gedit /etc/hosts.allow" and added a line that said "portmap : [Synology IP address]," using the address I had just found in Main Menu > System Information.  Next, I typed "sudo gedit /etc/hosts" and added a line near the top that said "[Synology IP address] [Synology Server Name]," in the same format as the other lines there.  (The server name was shown in Main Menu > System Information.)

Continuing with the NFS webpage's instructions, I was supposed to type something along the lines of "sudo mount [Synology Folder] [Local Folder]."  For that purpose, I understood that Synology Folder = [Synology IP address]:[Synology Shared Folder].  But I was not sure what the Shared Folder part was supposed to be.  Was I supposed to refer to the LUN or the iSCSI Target on the Synology unit?  Since the User's Guide (p. 41) said that an iSCSI Target was "like a connection interface," and that all the LUNs attached to it would be attached to the operating system, it seemed that I would need only one target, as I had set it up.  But now that I had learned more about security on the Synology, I had changed my mind about the number of shared folders I wanted.  I just wanted two, each 900GB in size:  one to contain stuff that shouldn't be changing very often, and that only the administrator should have write privileges for, and one for everything else, i.e., for the stuff that I would want to be able to mess with on a daily basis.  So after changing the LUNs and target in Storage Manager, I guessed that I would be creating two folders using the pattern of "/home/[username]/[foldername]" (where "username" would be "ray" in my case) -- one for each of the two LUNs on the Synology.  One of them was called SYNDATA.  On that basis, I typed "sudo mount [Synology IP address]:[Synology 900GB folder name] /home/ray/SYNDATA."  This gave me "access denied by server while mounting [Synology Folder]."  Not a desirable answer, but at least it was a reply of some kind!

By now, I was completely confused, and more than a little irritated at how very long this was taking.  The NAS was supposed to be simplifying my situation, not making it more complex.

It did seem, at this point, that it might have been easier to troubleshoot this if I had been using a computer as my NAS:  I could have gone into it and typed various commands to maybe get a bit more insight on what was happening in there.  A search for that error message led to the suggestion that I type "/usr/sbin/rpcinfo -p" to see what ports the server was using, but that gave me a "No such file or directory" error.

I decided to put in a support request at Synology.  The form required me to enter the Firmware Version -- but, of course, this was not provided in the System Information dialog.  I just entered something that seemed approximately right.  It also asked for the serial number -- and that, they helpfully indicated, was located on the bottom or perhaps the rear of the unit.  After turning it around and risking unplugging it, doing gymnastics to hold it while typing, I realized that, well, they might have mentioned that that bit of information actually *was* in the System Information dialog.  But when I got down to the part where they were ready and listening to what I had to say, I was not sure what to type.  There wasn't an option of talking to (or even chatting with) a live person.  I had to type something.  But what?  How could I possibly explain all this in a few words?

What I needed, somewhere in the Synology software, was a tool that would tell me what was happening.  "You have connected to a computer" or "You have not connected to a computer," etc.  I wasn't sure -- I hadn't done much networking before -- but I suspected that I could get that kind of information by using regular Linux commands on a computer in a network.

I decided that what I would tell the Synology people was just that they should look at this post.  I had identified a number of areas they could improve; and if they really got on the stick, they might even be able to respond in time to help me, before I returned the unit to the vendor or resold it.  The unit had more than a dozen positive remarks from other purchasers at Newegg, so I was hopeful.  But meanwhile, I started a post on the alternative of using a separate computer to create my own NAS.

Ubuntu 10.04: Connecting to Synology DS109 NAS

I had tried once before to connect a Synology DS109 network attached storage (NAS) device to a computer running Ubuntu 10.04 (Lucid Lynx).  It was a frustrating, confusing experience.  But when I rebooted that computer into Windows XP, it connected it right away, with a little help from Synology's extremely responsive tech support.  Now I was ready to try again in Ubuntu.

The first part was easy.  I navigated to the folder where I had placed the downloaded, unzipped copy of Synology Assistant for Linux.  That is, in Ubuntu's Applications > Accessories > Terminal, I typed "cd /media/LOCAL/[foldername]."  (If there are spaces in the foldername, you would have to put quotation marks around everything after "cd.")  This folder now contained a couple of "How to Install" (or Uninstall) items and a file named "install.sh," along with the .tar.gz file.  I typed "sudo sh install.sh" and that installed Synology Assistant.  I designated /usr/local as the install path.  It told me that I could run the Assistant program from /usr/local/SynologyAssistant/SynologyAssistant, or through the symbolic link at /usr/local/bin/SynologyAssistant.  I right-clicked on the word "Applications" on the menu and chose Edit Menus > System Tools > New Item.  I filled in the name as Synology Assistant and I browsed to the symbolic link and selected it.  Now I had a working menu link under System Tools.  I ran that and got the Management tab in Synology Assistant.  I double-clicked on DiskStation and that opened up a tab in my Internet browser.  In theory, I could access the Synology DS109 from here.  I closed the Assistant and logged in on the browser tab.  I went into the File Browser and, what do you know, it was all working fine.  Having already run the firmware updater on the DS109, as described in the previous post, I didn't need to do that again, as I confirmed in Synology's Control Panel > DSM Update.  In short, it seemed that the easy approach, for this part, would have been for me to start with the Windows setup, where I was more familiar with everything, and set up the DS109 that way, and then come to this point in Ubuntu.

Now there was the matter of being able to work with files and folders on the DS109 from within Nautilus or Terminal.  This was where I had gotten stuck last time.  In Nautilus, near the top left corner, I clicked on the Tree option that I normally used and changed it to Places.  It showed several items that seemed to be a legacy of my previous attempts to set up networking. 

At this point, I contacted Synology tech support again.  They had used TeamViewer last time to troubleshoot my problem, so I went to PortableLinuxApps.org and downloaded TeamViewer 5.  It downloaded to my home folder.  I wasn't able to figure out how to run it, so I posted a note on it.  I tried to show my network devices by typing "sudo lshw -C network," but that just showed me my ethernet controller.  Meanwhile, though, Synology tech support pointed me toward an article on their wiki, on how to map a network drive in Linux.  In essence, they had me type these lines:

sudo mkdir /mount/SYNDATA
sudo gedit /etc/cifspwd

(I tried using that second line because what they actually recommended, "echo username=[username] > /etc/cifspwd," gave me a "Permission denied" error, even when I preceded it with "sudo."  So on the first line of that blank new cifspwd file that I was creating in gedit, I typed the Synology username I wanted to use, and on the second line I typed that username's password.  I hit Enter after the password but didn't type anything on the third line.  I saved and closed the cifspwd file.  This, however, was not the right approach.  After some trial and error, I guessed that maybe what I was supposed to put into the cifspwd file was not this:

[username]
[password]

but rather this:

username=[username]
password=[password]

I had assumed that the program would know that what I was typing on the first line was the username, but now it seemed that, no, I had to say so.  So if my username was "ray," then the first line would read "username=ray."

This got me partway there.  The other part was to type "sudo gedit /etc/fstab" and add these two lines to the fstab:

#Entry for SYNDATA
//192.168.2.1/SYNDATA                /media/SYNDATA        cifs    user,uid=ray,gid=users,rw,suid,credentials=/etc/cifspwd,iocharset=utf8 0 0

where 192.168.2.1 was the number I got from Synology's Main Menu > System Information > General tab > Network section > IP address and "ray" was the username on the computer (not on the Synology).  I found that, if you had more than one device like SYNDATA, you could still use the same IP address on a separate fstab line, and otherwise everything except for the name (e.g., SYNDATA) would be the same.  After finishing my edits to fstab, I saved and closed it and typed these lines:

sudo chmod 0600 /etc/cifspwd
sudo mount -a

First time around, when I had the wrong fstab entry (i.e., referring to "synologybox" rather than 192.168.2.1), this gave me an error:

mount: wrong fs type, bad option, bad superblock on //synologybox/SYNDATA, missing codepage or helper program, or other error (for several filesystems (e.g., nfs, cifs) you might need a /sbin/mount. helper program)
In some cases useful info is found in syslog - try dmesg | tail or so

I had also gotten another error, "mount point /media/SYNDATA does not exist," but I had fixed that by typing "sudo mkdir /media/SYNDATA."  In the course of troubleshooting, again with great help from the Synology tech support lady, I also discovered the alternative of mounting the DS109 from the command line, with something like this:

sudo mount -t cifs //192.168.2.1/SYNDATA /media/SYNDATA -o username=[username],password=[password],iocharset=utf8

A bit of playing with that led me to discover that the password I was using contained an exclamation mark (!), and while that was no problem when logging in from the Windows machine, it was a problem on the Ubuntu machine, at least if I was logging in from the command line.  After adjusting to resolve that problem, I was able to connect to the Synology, and now I was showing SYNDATA as a drive in Nautilus, just like other partitions.  I still wasn't sure what to do about those Windows Network and DISKSTATION entries that showed up in Nautilus > Places > Network, but I decided to let that be a problem for another day.  I typed "sudo gedit /etc/fstab" and corrected the line to read as shown above.

Incidental notes:  another troubleshooting step taken at some point (not sure when) was to type "sudo mount -t cifs."  Another problem was the demand, "Enter password to unlock your login keyring," but every password I tried failed.  I wanted to bail out, but the thing kept giving me the same dialogs.  I had to use Force Quit to get it to shut up.  Second time around, though, I tried Cancel instead, and that let me go right on through.  Weird.

Also, at one point in the troubleshooting process, the computer became completely unable to contact the outside world.  Firefox wasn't reaching webpages, and some of my Synology-related commands were producing a "Network is unreachable" error.  That seemed to be a pretty common problem.  I fiddled with some random commands, and it seemed that one of them had adjusted the situation.  The command in question might have been "dhclient eth0" but more likely was "/sbin/route add -net 0.0.0.0 gw 1.1.1.1 eth0" (replacing 1.1.1.1 with 192.168.2.1 in my case -- see above).  But then that turned out to be a false dawn; I was soon back at the "network is unreachable" error.  A day later, however, without any intervention by me other than to reboot the system, the computer was able to go online.

So at this point, writing up these notes a day or two after I was finally able to get to the Synology DS109 through the Ubuntu machine, the main things that I did seem to have been to add the username and password to the cifspwd file in the correct format and use the right syntax in the fstab entry, as shown above.

Ubuntu Do-It-Yourself Network Attached Storage (DIY NAS): A Preliminary Look

I had just done an enormous amount of work in an unsuccessful attempt to get a Synology DS109 network attached storage (NAS) device to work in my Ubuntu 10.04 system.  It was an expensive unit, on my budget, even if it was near the bottom of Synology's line of products, so I was hoping for good things from it.  But I was not able to figure out why it wasn't connecting with my computer.  So while waiting for a reply from Synology's tech support, I did a search for do-it-yourself (DIY) alternatives.  This post describes a bit of what I found.

What I was hoping to find, in a DIY alternative, may be summarized in this excerpt from the previous post:

I decided to go ahead with the Synology project for now; I could return or sell the device if it really wasn't what I wanted.  I probably could have assembled another computer at equal or lower cost, with far greater potential storage capacity, with more RAID options, with a more powerful processor (for e.g., checksum calculations) if needed, with what might prove to be more options in the choice of software packages and commands to manage and adjust it, and with more flexible hardware troubleshooting options (i.e., more than just fix it or replace it) in the event of malfunction.  Its drawbacks would include time and expense for software and hardware selection, learning, installation, maintenance, and troubleshooting; physical space requirements; power consumption; and noise and heat generation.

If the Synology unit had been easy to use, I wouldn't have been able to generate that list of potential advantages of a DIY alternative.  I accumulated that list during the process of writing up the hassles I was having.  So now it was a question of how true those observations really were.

One thing for sure:  if I had taken seriously the idea of building a NAS myself at the outset, I would not have bought the Synology unit.  I did, in fact, have an old computer sitting around, one that I rarely used, mostly just for troubleshooting random hardware problems.  I was willing to convert it to another function. So, right there, I did have much of the hardware that I would need.  Its case design would accommodate a number of drives, if I decided to build a RAID NAS that would require that.

That took care of some of the objections to a DIY NAS.  What about space, noise, heat, and power?  There was no comparison:  the Synology was such a cool, quiet, sleek little thing compared to that whole computer case and its monitor and keyboard.  Even if I put the peripherals in a drawer and managed the server remotely (assuming that was possible), there was still the noise from its fans and power supply.  The trade-up in expandability and flexibility (with e.g., RAID) would come at a cost.  And that was the real question:  did I want the additional capabilities badly enough to accept the drawbacks?

Then again, it occurred to me that I didn't absolutely have to have the server remain on constantly.  Couldn't it hibernate during slack periods?  For noise reduction, couldn't I park it in a closet?  This seemed like something worth experimenting with.

What about hardware hassles?  I could probably just plug in the drives and, optionally, a RAID controller and be done.  The Synology unit did not have a RAID option, and it did not come with a drive.  The DIY NAS would have more things that could fail, but failures did not happen often, and with an optional RAID setup it would be better equipped to absorb them.  In terms of hardware, the DIY NAS was the winner.

And software?  The Synology software package had a nice GUI that, for all its good looks, had managed to confuse me and had thus failed to deliver a working solution.  If the Synology people came through on my tech support request, I would be ahead of the game there; but my request had been so broad and confused that I doubted they would be able to help much.  If it was a matter of devoting another five or ten hours, I was leaning toward trying something new, rather than beating my head against the wall with more efforts to understand the Synology software.

I decided, though, that I had probably better take a closer look at the software I would be using.  Ubuntu came with software RAID, and I had already had a bit of experience with that.  But what about NAS -- what software would I use for that?  I had gotten the impression that NFS was a good alternative to Samba for a Linux network -- simpler and faster, but possibly not as secure and apparently not as good for interfacing with Windows machines.  The Synology unit used NFS.  But this didn't really answer the question.  What software -- really, what operating system -- would I use to manage the DIY NAS?  Sources cited on the Wikipedia page for FreeNAS made it sound like a great solution.  It was apparently UNIX-based, and thus was some kind of cousin to Ubuntu, but it seemed I would have to invest some additional time to learn FreeNAS.  Ubuntu Server seemed like a more familiar, better-supported, and more flexible alternative.  Openfiler was another possibility.  A lot of people swore by Windows Home Server; I just didn't want to pay $100 for the privilege of going back in the direction of relying completely on Microsoft software.  Going in a different direction, there also seemed to be routers with hard drive connections, though I wasn't fond of the USB connection offered by the one I saw.

Those thoughts led to a thread that made me ask whether I wanted an NAS or a home server.  The tradeoffs described above were echoed in another thread I found, but now the discussion had mutated a bit.  If I was going to use a computer as an NAS, it seemed I might as well make it a home server.  In fact, that's probably how I had been thinking of it anyway:  a machine that could do whatever a computer could do, including RAID as well as NAS.

By this point, a couple of things had happened.  I had downloaded a copy of Ubuntu Server and had decided to try setting it up on that old computer, to see how easy it would make things for me in terms of network storage and RAID options.  I had read enough webpages to persuade me that setting up a home server could be somewhat time-consuming and thus would ideally be approached, for my purposes, as a longer-term project:  install the operating system, tinker with the hardware, and gradually move toward comfort with its maintenance and other requirements.  And I had heard back from the Synology people via email, not once, but twice in the space of three hours in the evening, East Coast time.  They were offering to set up a TeamViewer session with me for the next day.  So my working plan, at this point, was to get the Synology going, if I could do so the next day.

Synology DS109 NAS: No More Connections Can Be Made

I was using a Synology DS109 network attached storage (NAS) unit.  Everything was going along fine, and then suddenly I could not connect.  In Windows XP, I was getting this error message:

An error occurred while reconnecting D: to \\Diskstation\SYNDATA
Microsoft Windows Network: No more connections can be made to this remote computer at this time because there are already as many connections as the computer can accept.
This connection has not been restored.

I did a search but didn't find anything useful.  I was pretty sure it wasn't just a Windows XP problem, since I was also suddenly unable to connect using another computer running Ubuntu 10.04 (Lucid Lynx).  (It might also have been possible to test this on the Windows machine by just rebooting with an Ubuntu live CD; not sure.)  The best I could get in Ubuntu's Nautilus > Places was "Unable to mount SYNDATA," and it didn't show up at all in Nautilus > Tree.  Both machines were able to access the Internet; they just couldn't access the Synology unit.

Weird thing, though:  using Synology's web-based DiskStation Manager (DSM) 3.0 > File Browser on either machine, I was able to view the contents of SYNDATA on the Synology unit.  I was not able to view the contents of an eSATA drive connected to the Synology unit, however.  This made me wonder whether the eSATA drive was the problem.  I went into DSM > Control Panel > System > External Devices, selected the eSATA drive, and clicked Eject.  When the drive's icon disappeared, I disconnected it and turned it off.  This did not seem to make a difference, though.

I wondered if maybe I needed to do some kind of power cycle, like when a router or modem would start malfunctioning and you would have to power it down, disconnect it, wait 30 seconds, power it back up, etc. in order to get it working again.  I went to DSM > Main Menu > Shutdown and chose the shutdown option.  Its blue light was blinking, but it was still on.  I disconnected its ethernet cable.  The unit stayed on.  After five minutes, I pressed the power button next to the blue light.  This had no effect.  I pulled the plug and the lights went out.  I shut down both computers and waited a couple of minutes.  Then I started the computers and the Synology, but left the eSATA drive off.  The situation had not changed.

I noticed that the Status light on the front of the Synology unit was off.  The LAN light was on, solid green, and the Disk light was flashing.  It may have been like that before, though I didn't think so -- it seemed like something I would have noticed.  I went into the web-based DSM.  When I tried to log in, it said "Processing.  Please wait."  The Disk light on the DSM finally stopped flashing, the unit beeped, and the Status light came on as solid green.  Apparently it had been doing a disk check.  I was now able to access the SYNDATA partition on the Synology unit via the Windows XP computer.  The Ubuntu computer was still not able to mount that partition.  In Ubuntu's Terminal, I typed "sudo mount -a."  That did it; it was now able to access the unit as well.  I turned on the eSATA drive.  The Windows XP computer was able to access it.  The problem seemed to be fixed.  The solution was apparently to let the Synology unit sit there until its Disk light was done flashing or, failing that, to power it down, power it back up, and let it clear its head.

Synology NAS: Mapping the Network Drive

I had newly installed Ubuntu 10.10 and was trying to communicate with my Synology DS109 network-attached storage (NAS) unit.  I had previously resolved some problems with this unit, but some had remained unresolved; and now, in any case, I was starting over.

I had downloaded and installed DiskStation Manager (DSM) 3.0, the Synology Assistant, and the User's Guide.  DSM was a web-based program, apparently running on the DS109, that I accessed by simply typing the DS109's address (e.g., 192.168.2.1) into the Firefox address bar.  I was able to connect to the DS109 by typing the username and password that it needed (i.e., not my Ubuntu username and password).

As outlined in a previous post, I had also created a mount point ("sudo mkdir /media/SYNDATA") for the DS109's SYNDATA partition.  The fstab (i.e., "sudo gedit /etc/fstab") contained a line that had worked previously to let me contact that partition.  The line I was using was this:

//192.168.2.1/SYNDATA  /media/SYNDATA  cifs  user,uid=ray,gid=users,rw,suid,credentials=/etc/cifspwd,iocharset=utf8  0  0

where "ray" was my Ubuntu user ID, not my DS109 user ID.  The DS109 user ID was contained in the /etc/cifspwd file; and now, as I looked at this, I realized that reinstalling Ubuntu from scratch had surely wiped out that file.  So I recreated it ("sudo gedit /etc/cifspwd"), using my DS109 user ID and password, in this form:

username=[DS109 username]
password=[DS109 password]

and that's all that file contained.  Example:  if my DS109 username had been Joe, the first line in this two-line file would have been "username=Joe," and the second line would have been "password=JoesPassword" (wahtever that user's actual password was).  Then I typed these commands

sudo chmod 0600 /etc/cifspwd
sudo mount -a

These were the basic steps recommended in a relevant page in Synology's wiki.  The problem -- or at least *a* problem -- as I eventually figured out (or re-figured; Synology's tech support may have originally suggested it), was that the "credentials" part of the fstab line was not working.  If I replaced "credentials=/etc/cifspwd" with "username=Joe,password=JoesPassword" (and then saved fstab), then the "sudo mount -a" command worked:  SYNDATA appeared in Nautilus like any other partition.  So what would happen if I put exactly that -- username=Joe,password=JoesPassword -- on the same line in /etc/cifspwd, instead of putting them on two separate lines?  No dice.  The cifspwd file was a dud.  I left the username and password information in the fstab, and deleted the cifspwd file ("sudo rm cifspwd").

So the short answer I arrived at, here, was that the Synology wiki was wrong, at least for my purposes.  I needed to take all the other steps -- creating a mount point, etc. -- but instead of creating the cifspwd file, I just needed to enter a line in /etc/fstab of this form:

//192.168.2.1/SYNDATA  /media/SYNDATA  cifs  user,uid=[Ubuntu username],gid=users,rw,suid,username=[Synology username],password=[Synology password],iocharset=utf8  0  0

and possibly the "iocharset" part was optional.

Windows 7 Fails to Detect Other Computer on Network

I was becoming acquainted with Windows 7.  Sometimes, when I booted it up, it would immediately recognize the other computer (running Windows XP) on my home network, and would also recognize the (Linux-based) Synology Network Attached Storage (NAS) device I had connected.  At other times, unfortunately, the Win7 computer would only see itself.  This post describes steps I took to resolve that inconsistency.

I did a search on this problem.  I was inspired to undertake this investigation after I used System Restore to restore an earlier state of the computer.  Those other devices were now not visible in Windows Explorer.  They had been visible just a few minutes earlier.  To my knowledge, I had not done anything that would have made those devices more visible, or less so.

When I searched, I noticed a post in which someone said that Windows 7 was also losing track of drive mapping after it went into sleep mode.  I wondered if that was related.  The previous day, the computer had magically mapped drive D, a network drive on the Synology NAS, without any instruction from me to do so.  The poster said that he was experiencing both of these problems.  That particular thread concluded without an indication of a solution.  One poster said, "Ultimately this is just the nature of the way networking is sometimes."  But it seemed to me that it had never been that way between the XP machine and the NAS, or between the NAS and the Ubuntu setup that I had been using before I got Windows 7.

I wondered if it was somehow an XP problem.  The WinXP machine was currently in touch with the NAS.  Was it possibly barring the Win7 machine from seeing either itself or the NAS?  I rebooted the WinXP machine, but that didn't make a difference on the Win7 machine.

It wasn't a hardware problem, or even a networking problem per se.  Access to the Synology unit was through a web-based program.  On the Win7 computer, I could go into that Synology program and could communicate with the Synology NAS unit.  Synology could see the NAS unit, but Microsoft couldn't.  Apparently whatever was keeping Win7 from seeing the NAS was also keeping it from seeing the WinXP machine.  It was all or nothing:  either Win7 could see them both, or (as at present) it could see neither.

After going online in Internet Explorer and accessing the Synology NAS from the Win7 machine, I rebooted the Win7 machine.  That did not make a difference.  The Win7 machine was still unable to see the others.

In Control Panel > Network and Sharing Center > Troubleshoot problems, I tried the Incoming Connections option and said, "Find this computer on the network."  It came back with this advice:

Reconfigure your network

To prevent problems other computers or devices might have when connecting to your computer, no more than one device should perform network address translation (NAT).

I followed the link into Windows Help and Support, but that wasn't actually too helpful and supportive.  I clicked Next, and the Incoming Connections troubleshooter confirmed, "More than one device is performing network address translation (NAT)."  So, OK, which device?  I clicked "View detailed information" and went into Detection Details.  All I could find there that looked like it might be informative was a Network Diagnostics Log.  Following the links there in the Help dialogs, it seemed that, to open that up, I would have to use ThermaData Logger software.  This software seemed to be almost completely unknown through the vendor, ETI Software, that Win7 pointed me to, but I did find plenty of links for it elsewhere.  I had no idea why Microsoft required me to download a 29MB file from a slow connection just to read a log file.  While I was waiting on that, I found ThermoWorks -- the need for using thermal logging software was another mystery -- and was right on the verge of downloading their ThermaData Software Suite for Windows when I looked back at the Help dialog and decided to try instead downloading ThermaData Studio 1.0.5, which was apparently an entirely different deal.  That turned out to be a 12MB file.  While that was downloading, I went back to the dialog and clicked on the "Other Networking Configuration and Logs" link to open NetworkConfiguration.cab.  That led me to two text files:  ipconfig.all.txt and route.print.txt.  Neither contained any obvious references to NAT.  I installed ThermaData Studio.  Back in the dialog, I tried again on the link to the Network Diagnostics Log.  ThermaData Studio wasn't going to read it right there on the spot, so I downloaded the log and tried opening it from there.  But when I double-clicked on it, I got a message, "Windows can't open this file."  I went into the Start Menu and opened ThermaData Studio from there and tried to use it to view the file that I had downloaded.  At first, it didn't see anything -- it was looking for .msdb files -- but when I told it to look for .etl files, it found the download.  It gave me a completely empty file.  ThermaData Studio looked like solid software, but since I did not need it after all, I uninstalled it.

We were left with the question of which devices on my system were set to NAT.  Trying another approach, I disconnected the WinXP machine from the network and re-ran the Win7 Incoming Connections troubleshooter.  That didn't eliminate the NAT problem.  I reconnected the WinXP machine, disconnected the modem from the router, and ran the troubleshooter again.  Now the NAT problem was gone, though now there was a new problem, where the troubleshooter said it needed more information.  So, OK, possibly the modem plus at least one other device was doing NAT on my network.  I had seen a post indicating that modems and routers can both do NAT, so I plugged everything back where it belonged and looked at the pages on port forwarding and putting a router into bridge mode that that post linked to.  Following what the latter seemed to be saying, I looked at a sticker on the bottom of my modem.  (I didn't seem to have a manual for it, but could probably have downloaded one.)  It gave me an IP address to enter into my Internet browser; and when I went to the appropriate page, it asked me for a code that appeared on that sticker.  This led me into the configuration software for the modem.  After poking around for a minute, I found a page for the modem's PPP location.  This seemed to be what I wanted.  It gave me two options:

PPP is on the modem.  This is the normal mode for this modem.  The PPP session is initiated from the modem.

PPP is on the computer, gateway or router.  This should only be used if you need to run a PPPoE client on your PC or you use another device (e.g., gateway or router) to initiate a PPPoE session.  This is often referred to as "Bridged" mode.

Since option A wasn't working for me, and since the post seemed to be saying that I should use option B, I switched to that and saved the change.  This gave me a Location Warning.  It said,

When using Bridged mode, your access to the modem becomes limited.  To return to the DSL modem user interface after this change you need to directly connect your PC to the modem without any gateway or router between the modem and the PC, and configure your computer appropriately.

Configure the IP address of your computer to be on the same network as the modem by using an IP address of the form 198.168.1.x (except 192.168.1.254) and a network mask of 255.255.255.0.

You may also return to the DSL modem user interface by resetting the modem back to its initial defaults.  All configuration changes and other settings will no longer be available if this is done.  To reset the modem press the "Reset" button located on the back of the modem.

We still had a problem.  The modem was supposed to be restarting, but it wasn't working.  It had three green lights on, including the one for the ethernet (i.e., router).  But why wasn't its Internet light on?  I unplugged its power cord, waited a minute or so, and plugged it back in.  That didn't help.  I tried the same thing with its Internet (i.e., telephone) cord.  When it was unplugged, the modem's DSL light was flashing red.  So I seemed to have a mistaken understanding of the difference between its DSL and Internet lights.  Well, whatever.  It wasn't working, is the point.  I thought that possibly AT&T (my ISP) needed the modem to be in the other mode.  I thought about calling them to ask, but Christ, to enter again into that vale of tears:  no way.

Well, I would have liked to research the modem situation further, but there was just one problem:  I couldn't, as I now had no Internet connection.  I ripped off the sticker on the back of the modem that said, "Remove only if advised by tech support" and there, in all its glory, behold:  the Reset Hole.  I jammed a paper clip into it and watched in amazement as this achieved ... nothing.  It seemed the Reset Hole had gone stale.  It took a couple of tries, and possibly the discovery that this unit required a minimum of 30 seconds of pressure in the hole to achieve the desired reset.  Even so, I could get online only by cabling the computer directly to the modem.  The router seemed to be dysfunctional.  There was, inevitably, a call to AT&T after all, and it actually took only ten minutes

I went back to the modem's webpage, but was now getting "Unable to connect."  Taking plan B, I cabled the WinXP computer directly to the modem, as advised above.  But still, no joy.  No Internet light on the modem; Unable to connect in Firefox.  Now I had really done it.  I had gone and given myself no alternative but to call AT&T.  A half-hour later, we emerged with the discovery that I, in keeping with the spirit of the event, had lost my router password and unfortunately could not go online to figure out how to reset it, given that the reset button seemed to be having no effect no matter how thoroughly I massaged it.  Oh, and the modem was back in its original mode.  End of bridge mode strategy.

I ran a search on this reset problem.  It produced some possibilities.  One was that I needed to reset my TCP/IP preferences to match the router's IP address.  Another was that I just wasn't following the right steps to reset it.  Apparently it was too early to call it a brick; but even if it hadn't been, there seemed to be some kind of de-bricking option.  Or maybe I just needed to go through the full set of steps for setting up the network properly.  The part that I may have left out, in resetting the router, was that I did not disconnect all except the power cable before doing the reset.  So I did that now, and held the reset button down for an overly long time.  I replugged the cable between it and a computer.  In the computer's web browser, I went to 192.168.1.1.  This connected me to the router's webpage.  The password to get in, after resetting, was admin.  Now I set Wireless SSDI Broadcast to Disable.  The webpage said I needed to initiate the push-button setup at this point.  It seemed they were referring to the backlit Cisco Systems logo on the front of the unit; pressing it revealed that it was in fact a button, and this produced a message on the webpage:

Accepting clients!

You will be returned to the previous page after SES configuration completed.

It then did its thing for a couple of minutes, and then I was back at the webpage.  The manual seemed to indicate that WPA2 Personal would provide the best available security for my setup.  I enabled Wireless MAC filtering.  The manual said that the option to Filter Internet NAT Redirection "uses port forwarding to block access to local servers from local networked computers."  That sounded vaguely like what someone had said I needed to make my network work again, so I enabled it.  A search led to the advice that I should not enable these until I needed them.  I disabled Wireless Access Web, in this wired setting.  A few more settings, and then I was done -- and still unable to connect to the router.  The troubleshooter was going to be unable to give me much help, it seemed until I connected the router to the modem, so I did that.  That still wasn't working, so I used the router's webpage Administration > Diagnostic options to ping the local IP address of 192.168.1.1.  That worked, but was I just pinging the router itself?  I tried 192.168.1.100.  That worked too.  I thought maybe the Traceroute diagnostic would be more helpful.  It wasn't.

The manual gave some troubleshooting steps.  Following its guidance, I made sure the router's light was solid green.  The other instructions weren't applicable.  For a moment there, I gave up on life.  Then I ate a piece of chocolate and tried removing that NAT Redirection filter.  That wasn't the solution, but it gave me enough cockeyed optimism to try the Internet Connections troubleshooter.  It -- a veritable font of sharp-eyed discernment -- said this:

Your broadband modem is experiencing connectivity issues.

It said I had better power down the modem, wait 10 seconds until the lights were off, and then power it back up.  I decided to also plug its cable back in.  I was hoping that the troubleshooter would at least say, "Hey, we have found your modem -- so far, so good!" and I guess in a sense they did.  With everything duly de- and re-powered and cabled, I tried it again.  Now, by gum, we had a breakthrough:

Your computer appears to be correctly configured, but the device or resource (primary DNS server) is not responding.

What could this mean?  I had no idea.  I rolled the dice again on the Incoming Connections troubleshooter.  While that was running, I realized that a minor miracle had occurred.  Very quietly, while I was over there fixating on the Win7 computer, the computer on which I was writing this post had connected to the Internet -- through the cable, through the router, through the modem, through thick and thin!  And ... er, no, it hadn't.  Correction on that.

But at least there was a glimmer of hope.  By this point in the day, I had moved away from the Windows XP system, on the second computer:  I had rebooted with an Ubuntu live CD for maintenance purposes, and was therefore  writing this post in Firefox on that machine while it endured its maintenance throes.  And on that machine, for a minute there, I thought maybe it had made Contact.  But it had not.  I was in error.

Well, I had blown a good part of a day on a single troubleshooting problem.  This was, thankfully, a less frequent experience than it had been in years past.  I really and truly hated networking, and it probably showed, by this point, in my failure to grasp some obvious solution or to utilize some true-blue technique.  I really had no clue.  The problem wasn't with the modem or the Internet connection; I could save this post when I connected directly from the modem to this computer.  Possibly the problem wasn't between the Win7 computer and the router; the troubleshooter had felt that everything was in place there.

Trying something a little different, I got an ethernet switch off the shelf and connected both computers directly to the modem through that.  And, whoa, that changed everything instantly.  The Win7 computer popped up a dialog asking me to Set Network Location, and it was immediately connected to CNN.com, and the Ubuntu live CD spun up and updated this text shortly thereafter.  So.  It was the router.  I knew it all along.  What could this mean?  It could mean (a) the router was malfunctioning or (b) I did not have its settings right or (c) the real explanation, which I did not presently know.  Putting my money on (b), I reconnected the Win7 machine to the router, went to its webpage, and chose the Administration > Factory Defaults option.  When it was done wiping out all my hard work, it required the no-username, "admin" password entry.  I ran the Win7 Incoming Connections troubleshooter again.  It said it needed more info.  I tried it again with the modem connected to the router.  (CNN.com was not responding at that point.)  This came back with the message about how the modem was experiencing connectivity issues.

We seemed to have the beginnings of insight.  It appeared that I should have tried the ethernet switch and the factory defaults, right away, as alternatives to my custom configuration of the router.  Experiencing success with one or both of those alternative approaches would have clarified matters.

But that wouldn't be networking -- because, now that I had unplugged and replugged the switch a few times, it was no longer doing the job on either computer.  Everything was connected to it, as before, and the modem's lights looked right, but neither computer was able to connect.  With the switch still connected, I tried rebooting the Win7 computer.  It was no use.  The Win7 machine was still not able to see the world, and the Ubuntu computer was pretending to connect.  I powered down the switch and tried a direct connection from the modem to the Ubuntu computer.  Still crawling.  I powered down the modem for a minute.  That did it:  the Ubuntu machine was now going online without a sweat.  I tried the switch again.  That worked on both machines now.  So apparently the switch did get confused and need some time off.

The conclusion seemed to be that, if I needed a router, I needed to try a new one, and otherwise I should just use the switch and power it down for a while if it failed to work.

Both computers were now going online successfully.  What did the Win7 troubleshooters have to say about this?  The Internet Connection troubleshooter said that it "couldn't identify the problem."  This was apparently tactful speech:  it seemed to mean that it couldn't identify *a* problem, but didn't want to tell the user that s/he was imagining things.  The Incoming Connections troubleshooter said this:

Troubleshooting was unable to automatically fix all of the issues found.  You can find more details below.

Problems Found

Windows requires more information to diagnose the problem.

Here, too, there seemed to be a bit of a bullshit factor.  I had been taking these troubleshooters as though they meant exactly what they said -- that, in the latter case, there was a problem, though it was difficult to diagnose -- but now it began to seem that they might say this when there wasn't necessarily a problem.  Pointing me to an online source of the "more information" that the program needed was a funny gesture when, according to the troubleshooter itself, I might not be able to go online.  It seemed pretty lame, worthy of Windows 95.  After all, this was Microsoft's software reporting on Microsoft's software.

What remained, it seemed, was to choose between the switch and a new router.  That was a question for another post.

Synology DS109 NAS: Unable to Mount - Network Is Unreachable

I was running Ubuntu 10.04 (Lucid Lynx) on a computer to which I had connected a Synology DS109 network-attached storage (NAS) unit.  I had resolved a "no more connections can be made" error on a separate computer, also attached to the DS109, that was running Windows XP.  Now I had a new problem on the Linux machine.  This time, the WinXP machine was connecting to the Internet and to the Synology without a problem, but the Ubuntu computer (referred to here simply as the Ubuntuter) was not connecting to either.

The symptoms included the following:  in Firefox, I was getting "Firefox can't find the server" errors for most webpages; in Nautilus, I would get "Unable to mount" errors when I clicked on the name of a partition on the Synology; and in Synology's DiskStation Manager (DSM), its web-based access to the DS109, an attempt to log in to http://[IP address] (using the IP address from DSM > Control Panel > System Information) gave me a "Processing. Please wait ..." message.

I tried rebooting the Ubuntuter.  That achieved nothing.  Typing "sudo mount -a" gave me this:

mount error(101): Network is unreachable
Refer to the mount.cifs(8) manual page (e.g., man mount.cifs)

I typed "man mount.cifs."  From that, I gathered that I should type something like "sudo mount -ta cifs," though that precise command didn't work.  The "mount -a" command was supposed to mount everything in /etc/fstab, but apparently it could not mount the fstab items that had network locations.  I tried connecting the Ubuntuter directly to the modem, bypassing the router and the rest of the network (i.e., the Synology and the other computer).  This did nothing.  Apparently it was not just a Synology problem.  I rebooted with an Ubuntu live CD and tried Firefox that way.  It was not able to reach webpages either way (i.e., while connected to the router or directly to the modem).  It seemed I had a hardware problem.  I was using a new Gigabyte GA-MA785GM-US2H motherboard.  It looked like a few of its reviewers at Newegg cited intermittent problems in connecting.  The solution, it seemed, was to return the board or try adding a network interface card (NIC).  I tried the latter.

But while I was doing that, I noticed that the little plastic tab on the ethernet cable was gone.  It was possible for the plug to just slide out of the socket.  So I replaced the cable.  That worked on the next bootup.  So at this point the solution seemed to be either (a) if one reboot doens't work, try another, (b) the NIC connector is competitive and will get its act together if you install another card that might take its place, or (c) a better cable.  I gave it some time, to see which it would be.  After several days, I could say with confidence that the simple replacement of the cable made all the difference.

Ubuntu 10.10: Tweaked Installation

I had previously installed Ubuntu 10.04, and had arrived at a fast way of adjusting the basic installation to my needs. This post updates and simplifies the separate post in which I described that process.  Here, I was using Ubuntu 10.10, not 10.04.

This post begins with a basic Ubuntu setup already installed.  That basic installation process was very straightforward; but for those unfamiliar with Ubuntu, there were many webpages on how to install Ubuntu 10.10.  The question addressed in this post was, what additional steps did I need to take, in order to make Ubuntu look and act the way I wanted?  Of course, people will have various preferences.  This post does not go into that kind of individual detail.  It is more a matter of how to go about choosing and preserving one's desired setup.

In this case, I had installed Ubuntu 10.10 in a two-drive RAID0 setup.  I have written a separate post on that as well.  It looked and acted the same as a normal single-drive Ubuntu installation.  But the following discussion contains a few references to the setup described in that other post, for those who have come to this description from there.

The Home Partition

If I had been installing Ubuntu without using RAID, I probably would have decided, in the initial installation, to install everything in a single root ("/") partition.  But the RAID process had required the creation of a separate /boot partition, so I now had those two partitions instead of one.  Either way, though, my installation did not yet include a separate /home partition.  I did want a separate /home partition to be part of the mix, because /home was where all kinds of program settings were preserved.

I had retained a copy of my previous /home partition.  It was on a third hard drive.  That is, it was not part of the RAID array, and I did not plan to copy it into the RAID array.  RAID 0 is risky, in the sense that failure of any drive in the array means the end of the entire array and everything on it.  So I was just going to leave the /home partition on that separate drive, and back it up from there.  The question was, how should I get the new installation to recognize that separate /home partition?  I had struggled with this step previously, but now I wanted to write it up in simpler form.

On that third drive, I had a folder called Saved Settings.  In that folder, I had kept a copy of my old fstab (that is, the file called "fstab," from the /etc folder, viewable by typing "sudo gedit /etc/fstab").  I added lines from that copy into my current fstab, making sure that its lines referred to UUIDs (available via "sudo blkid") rather than to drive letters (e.g., sda, sdb), so that the commands in the fstab would still function if I rearranged partitions in my computer.  I also made sure it had a line referring to the correct UUID for the /home partition.  I saved and closed fstab.

To give /home a place to be mounted, I typed "sudo mkdir /media/home."  To prevent the newly installed (and nearly empty) /home partition from interfering with the selection and use of my preferred, preexisting /home partition, I typed "sudo mv /home /old_home."  I had meanwhile allowed Update Manager to install updates, and that process was done, so at this point I rebooted.  I got an error message, "Could not update ICEauthority file /home/ray/.ICEauthority."  I clicked through that, and after a moment my old, preferred desktop layout was there and seemed to be functioning normally.  (I worked through the ICEauthority problem as described in a separate post.  Basically, the solution was to make sure the user (i.e., ray, not root) had ownership of the home folder.)  The last step was to delete the temporary old_home folder I had created by typing "sudo rm -r /old_home."

Repositories

Having the home folder in place meant that about 90% of the work of installing and configuring programs was already done and saved.  This was one huge advantage over Windows XP installations, where the only programs that did not have to be reinstalled in the event of a new operating system installation were portable applications.  This section describes the relatively few steps that I did have to take to install applications and configure my Ubuntu system, as compared to the writeup in a separate post on Windows XP reinstallation.

I could not rely on my previously saved sources.list file to set up my repositories, since I was now dealing with a new version of Ubuntu.  Instead, I went into System > Administration and discovered that, unlike Ubuntu 10.04 (as discussed in a separate post), Ubuntu 10.10 no longer had a Software Sources option.  A search revealed that this change was made to make Ubuntu more user-friendly.  I could either edit the menu to add back the Software Sources option or use System > Administration > Synaptic Package Manager as an alternative.  Choosing the latter, I went into Synaptic's Settings > Repositories > Other Software and selected the non-source options.  In the Authentication tab, I saw a list of Trusted Software Providers, and the names on it were Ubuntu (archive, CD image, and extras), GetDeb, and Google.  I had no problem with any of these except maybe Ubuntu extras.  I wasn't sure if these had come from my previous installation or were pre-supplied with Ubuntu 10.10.  I could have hit "Restore Defaults" to find out, but then I would have had to figure out how to restore them.  I closed out of that and, back in Synaptic, clicked Reload.

In Terminal, I typed "sudo gedit /etc/apt/sources.list."  I saw that it contained a handful of repositories.  I wondered if there were others I should include, so I went to the Ubuntu Sources List Generator and got a list that was more concise and that also included a few third-party repos of interest (i.e., GetDeb, Google, Medibuntu, Wine, and X Updates).  I ran the commands in the "Getting the GPG Keys" list from the bottom of the page, one at a time.  In previous installations, I had saved such commands in a text file and had executed it, but that had made it easier to overlook error messages.  In this case, the Medibuntu command gave me "Unable to locate package medibuntu-keyring."  A search indicated that virtually nobody had gotten precisely that message.  Not a good sign.  A community documentation page gave me a different command to add Medibuntu:

sudo wget --output-document=/etc/apt/sources.list.d/medibuntu.list http://www.medibuntu.org/sources.list.d/$(lsb_release -cs).list && sudo apt-get --quiet update && sudo apt-get --yes --quiet --allow-unauthenticated install medibuntu-keyring && sudo apt-get --quiet update

... all on one line!  It also said that Medibuntu's repository is deactivated whenever you upgrade to a newer Ubuntu release, so this reinstallation would have to happen each time.  I copied and pasted that command and ran it.  It gave me an error message:

Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?

to which the answer was yes, of course, Synaptic is still running.  I shut down Synaptic and tried again.  This time, it ran.  I took another look at the Authentication tab in Synaptic (see above), and now Medibuntu was on the list of trusted software providers.  So the answer to my question was, this was my customized list.

I went back to the process of running commands generated by the Ubuntu Sources List Generator.  They ran without further difficulty.  I typed "sudo gedit /etc/apt/sources.list" again, and replaced its contents with the lines generated by that Generator.  I took another look at Synaptic's Authentication tab, and this produced an error indicating that I had duplicate entries for Medibuntu and, I think, something else.  But when I tried to figure out what that was about, the error went away, and I didn't seem to be able to get it back.  Anyway, the Authentication tab did show that I now had the five third-party repos that had interested me (above), so all that remained was to go into System > Administration > Update Manager > Check and download the additional updates that it detected.

Installing Programs & Other Adjustments

In Terminal, I navigated to my Saved Settings folder (basically, cd "/folder name/" -- using quotes because "folder name" has a space in it) and verified that I had a copy of the installed-software file that I had created, in my previous installation, by typing "dpkg --get-selections > installed-software."  Now that I wanted to restore the programs listed in installed-software, I entered these commands:

sudo dpkg --set-selections < installed-software
sudo apt-get install dselect
sudo dselect

That opened up dselect.  The dpkg command had provided the list of what I wanted to install, so all I had to do now, in dselect, was to arrow down and hit Enter at the Install option.  This gave me an option of installing a large quantity of stuff, and I said OK, do it.  That took an hour.  At the end, I declined to let it erase previously downloaded .deb files, when it asked.  The last time I used this installed-software approach, I got a bunch of errors after reboot, and had to work back through the process manually.  There were some errors this time, too (see below), but they did not appear to be related to the dselect process.

As before, I navigated to the folders containing other program downloads (with .deb, .gz, .bin, and .bundle extensions).  I typed "sudo sh [filename]" to install my .bin and .bundle downloads (e.g., GoogleEarthLinux.bin).  Double-clicking on the filename in Nautilus no longer installed my .deb downloads; instead, I had to right-click and choose "Open with GDebi Package Installer."  In the case of my Synology software, I typed "sudo sh install.sh."  I wasn't sure where to install it, so I told it to install in /home, just in case that would spare me from having to install it again.  But I should have said /home/ray.  When I was done with all installations, I went into Update Manager, and ran and reran it until I was all caught up.

GRUB2 menu edits were the same as before:  to get rid of the Memtest+ options, I typed "sudo chmod -x /etc/grub.d/20_memtest86+." To let Ubuntu remember which operating system it had used last, I typed "sudo gedit /etc/default/grub," changed the first line to be "GRUB_DEFAULT=saved," and added a second line that said "GRUB_SAVEDEFAULT=true."  To limit the number of Ubuntu kernels shown, I typed "sudo gedit /etc/grub.d/10_linux," added "GRUB_DISABLE_LINUX_RECOVERY=true" at the top, and changed two lines at the bottom to be three that read as follows:

list=`echo $list | tr ' ' '\n' | grep -vx $linux | tr '\n' ' '`
list=`version_find_latest $list`
done

I saved and closed that and typed "sudo update-grub."

I also needed to make some adjustments for VMware.  First, I typed "sudo vmware" and made some root adjustments there.  As before, I typed "sudo gedit [path][filename].vmx," for the .vmx file pertaining to this VM; and at the end of that file I added a line that said this:

bios.bootDelay = "10000"

and that bought me ten seconds instead of one or two, when that vmware logo came up.  In a variation from Ubuntu 10.04, the restricted drivers for my monitor were now at System > Administration > Additional Drivers.

Bugs and Other Problems

There were some problems.  First, BOINC would not suspend itself when the system was in use, so I just suspended it, period.  Also, as discussed in a separate post, there were some Firefox errors.  The solution there was to completely uninstall and reinstall Firefox, though possibly it would have been sufficient just to uninstall firefox-gnome-support and delete my profile.

Another problem was that Ubuntu was not clearly recognizing all local and network partitions.  The problem of mapping the drive in my Synology NAS required another separate post.  In that case, it came down to a problem with the line used to mount the drive in fstab.  It had seemed like there were other drive recognition problems, but evidently they sorted themselves out, or perhaps I was just mistaken.  At this point, the drives seemed to be recognized in good form.

There was also the problem that GParted wouldn't run.  It wasn't just in my installation; it wasn't running when I booted from the live CD either.  I guessed that this was some kind of brand-new bug in Ubuntu 10.10 that would be fixed shortly.  When I started GParted from System > Administration, it would start up, but then it would disappear after just a few seconds.  When I typed "sudo gparted" or "gksu gparted," it did the same thing, but it gave me an error message:

glibmm-ERROR **:
unhandled exception (type std::exception) in signal handler:
what: basicI_string::_S_create
aborting...

A search indicated that this was indeed a bug in Ubuntu.  It looked like a new release would be fixing the problem imminently.  Another problem:  Google Earth would not install.  I got this error message:

parser error : Document is empty
parser error: Start tag expected, '<' not found
Couldn't load 'setup.data/setup.xml'

The command I used was "sudo sh GoogleEarthLinux.bin."  The first response to it was "Verifying archive integrity... All good."  Just in case, I downloaded a replacement of GoogleEarthLinux.bin, but got the same result.  It looked like others had also had this problem.  It seemed to be another instance of Ubuntu 10.10 not yet having all the kinks worked out.  I started with a lengthy thread on the issue.  One post in that thread recommended a command-line alternative, which in full form went like this:

sudo apt-get install googleearth-package
sudo make-googleearth-package --force
sudo dpkg -i googleearth_5.2.1.1588+0.5.7-1_i386.deb

I tried that.  The make-googleearth-package command generated a lot of errors that included the sentence, "Can't extract name and version from library name."  I got that long package name shown in the last line (googleearth_5.2.1 etc.) from one of the last lines produced by the make-googleearth-package command:  it said this was the name of the package it was building.  (It also seemed to say that simply "googleearth" was the name of the package, but that didn't work.)  The third command (sudo dpkg etc.) seemed to run successfully.  There was also now a Google Earth icon in Applications > Internet > Google Earth.  I clicked on that, and it worked.

Another problem involved VMCI Sockets.  I have addressed that one in a separate post.  I ran out of time to continue this project at the time.  When I returned to it two months later, I had decided to stop trying to maintain a primarily Ubuntu machine, but instead to return to Windows 7 for the foreseeable future.