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 10.04: Sharing a Folder on an NTFS Partition

I had two computers running Ubuntu 10.04.  These machines were connected by ethernet cable through a router.  Both had Samba installed, and both had a shared folder set up as described in another post.  I had set up one of those shared folders on an ext3 partition.  As that other post indicates, I was able to see the contents of that shared folder from the other computer.  But without thinking about it, I had set up the other computer's shared folder on an NTFS partition.  Seeing a folder on that partition turned out to be a more complicated matter than I had expected.  This post describes my efforts in that regard.

Right away, I rediscovered that chown wouldn't work as expected with NTFS drives, and that it was therefore necessary or advisable to type "sudo gedit /etc/fstab" and change the lines for NTFS drives or partitions to something like this:

UUID=[UUID for the drive] /media/partitionname ntfs-3g rw,suid,dev,exec,auto,user,async,umask=000 0 0

and then unmount ("sudo umount /media/partitionname") and remount the partition.  Remounting would apparently force a look at the new contents of fstab, and could be done with "sudo mount /dev/sdc3 /media/drive1" or just "sudo mount -a" (assuming a folder named /media/drive1 had already been created (e.g., "sudo mkdir /media/drive1")).  That fstab line was one I had developed to replace the "defaults" word that appeared in some fstab lines previously:  it made all of the default settings explicit, and changed some of them.  Yet even with this change, when I tried to set the Sharing Options in Nautilus, I got this error message:

Folder Sharing

'net usershare' returned error 255: net usershare add: cannot share path /media/partitionname/folder2 as we are restricted to only sharing directories we own.

Ask the administrator to add the line "usershare owner only=false" to the [global] section of the smb.conf to allow this.

I was willing to go into smb.conf and make that change, but first I wanted to know why (as I confirmed with a right-click > Properties) root still owned that folder.  This led to the insight that NTFS filesystems (such as the one I was trying to share) did not remember ownership, so the partition would need to be reminded each time I mounted it.  One way to do this was to modify the fstab line to include user and group identifications:

UUID=[UUID for the drive] /media/partitionname ntfs-3g rw,suid,dev,exec,auto,user,async,umask=000,uid=username,gid=groupname 0 0

and then save fstab and unmount and remount the partition (above).  And yet that still didn't do it.  The better statement seemed to be, not that NTFS partitions needed to be reminded, but that they simply didn't have an ownership concept.  There seemed, then, to be no alternative but to type "sudo gedit /etc/samba/smb.conf" and add the line "usershare owner only=false" to its [global] section, as advised above.  I saved and closed that and tried Sharing Options again.  This time it worked, or at least it didn't give me an error message.

Unfortunately, the shared folder still wasn't showing up on the other computer's Places > Network list.  It sounded like the solution might be to try Sharing Options as root ("sudo nautilus").  Unfortunately, at this point "sudo nautilus" was giving me an error message on that computer:

(nautilus:23890): Unique-DBus-WARNING **: Error while sending message: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

I wondered what would happen if I stepped away from the NTFS situation for a moment.  I decided to try sharing a folder on an ext3 partition in that same computer.  I right-clicked on the ext3 partition in Nautilus, chose Create Folder, named the folder, went to the Share tab, and selected "Share this folder" and "Allow others to create and delete files in this folder."  This gave me an error message:

'net usershare' returned error 255: net usershare add:
cannot stat path /media/partitionname/foldername to ensure this is a directory.  Error was No such file or directory

I guessed that this might be because I had gone directly to the Share tab without first clicking Close in the Basic tab there in the P4 Share Properties dialog.  So, OK, I saved the new folder first, and then right-clicked on it in Nautilus and chose Sharing Options.  This time it went OK.  I went into System > Administration > Samba, as described in the other post, and added this folder there.  But I still wasn't able to see it from the other computer.  I rebooted this problematic machine and tried again.  In doing so, I noticed that GParted and some other things were still running on another desktop, so that may have explained why "sudo nautilus" worked OK after the reboot.  The sharing step just described also worked OK.  But Places > Network on the other computer still didn't show the problematic computer.  

I was just about to change some hardware and reinstall Ubuntu on that machine anyway, so I deferred further effort on this project until after that was done.  At that point, though, I found a better folder-sharing solution by using a Synology network-attached storage (NAS) unit.

Recognizing Partitions Automatically in Ubuntu 9.04

In Ubuntu 9.04 (Jaunty Jackalope), disk partitions normally remain unmounted until you mount them manually. One way to do this is to start Ubuntu's File Browser (also known as Nautilus). You can do this by choosing the Places > Computer menu option. In File Browser, just double-click on the drive you want to mount, and its name will appear under the File System > Media folder there in File Browser. You can also mount drives by typing commands into Ubuntu's command-line window (Applications > Accessories > Terminal). First, type "sudo mkdir /media/[drivename]" to create a mount point. After doing this for all unrecognized drives, type "sudo mount -a".

But instead of doing this sort of thing, I wanted the system to recognize my drives on bootup, so that I would not have to mount them manually each time I rebooted. In my first approach to this problem, I typed "sudo ntfs-config." This approach worked OK on one computer, where I was doing a clean installation -- where, that is, I had formatted the partition before installing 9.04 on it. But on another computer, I installed 9.04 on top of 8.04 without formatting the partition. This was advantageous in that it preserved lots of files and settings from before. The drawback was that I was running into funky problems with ntfs-config.

On this system, I got an error message when I ran ntfs-config. The message was, literally, "Error : An error occured when trying to configure [partition name], please retry. Thanks." (For those who are searching with the correct spelling, let me retype that error message: "Error: An error occurred when trying to configure . . . ." When I tried to examine the partition in GParted (i.e., System > Administration > Partition Editor (see above)), I got this: "Warning: Unable to read the contents of this file system!" The partition had been available a minute earlier, when I had booted into Windows XP, and I had shut down WinXP normally before rebooting into Ubuntu. So I didn't think the partition was truly hosed.

I found a very, very long thread on the subject, but post no. 2015 in that thread said the thread's advice was outdated for purposes of newer versions of Ubuntu. In another thread, someone said they got this error message after installing a newer version without formatting the partition, and solved it by deleting the mount points. I had a fresh backup of the partition in question, so I tried taking that approach. First, I opened File Browser and went to File System > Media > CURRENT. File Browser said that partition was empty. When I right-clicked on it, however, File Browser didn't give me an option of deleting it. Its Properties said it was owned by root, so I logged in as root (see above), typed "cd /media", typed "dir" to make sure CURRENT was there, typed "dir CURRENT" to make sure it was empty, and then typed "rm -r CURRENT" to delete it. I restarted the system, started File Browser, went to Computer (in the Tools bar), double-clicked on CURRENT, and it was there, with all its contents. CURRENT was formatted in ext3 (i.e., Linux). I had another partition that was having the same problem. It was formatted in NTFS (i.e., Windows). But now that I had rebooted, it too was available and looking fine.

I dropped this issue for the time being. Next day, when I rebooted, I found that, predictably, the various partitions were not mounted. In Terminal, I typed "sudo gedit /etc/fstab." My fstab file did not show the partitions I wanted to be mounted automatically. I reviewed one of my old posts on ntfs-3g. It seemed to say that ntfs-config was the solution. I tried running ntfs-config again. This time, it ran. It recognized two NTFS partitions. Now I just had two ext3 partitions to set up for automatic mounting. I went back into fstab and saw the lines that ntfs-config had added. I hadn't thought to save the fstab file from my previous installation; it would have been handy to copy over the relevant lines. From the previous post, I gathered that the trick was to write something like this in fstab:

/dev/sda3 /media/VMS ext3 defaults 0 0

for the VMS partition, and likewise for the other ext3 partition. I double-checked that I had the right device addresses by checking them in System > Administration > Partition Editor (i.e., GParted). I rebooted, but the ext3 partitions were still not automounted, though the NTFS partitions continued to be automounted nicely. I didn't know why the line just shown, for the VMS ext3 partition, did not work in fstab now; according to the old post, it had worked in Ubuntu 8.04. Ubuntu documentation said something about pysdm, so I looked into that. They suggested typing this into Terminal:

sudo apt-get install pysdm

but I saw it was available in Synaptic (i.e., Ubuntu's System > Administration > Synaptic Package Manager menu pick), so I used that instead to install pysdm. I typed "pysdm" at the Terminal prompt, but got an error message indicating that I had to have root privileges, so I tried again with "sudo pysdm." (Also available via System > Administration > Storage Device Manager.) That gave me a Storage Device Manager (SDM) window that listed some, but not all, of my partitions. I noticed that, if I started pysdm while I still had the foregoing /dev/sda3 line for my VMS partition in my fstab file, SDM would not give me an option of configuring the VMS partition; but if I deleted that line from fstab and then started pysdm and clicked on sda3, SDM would give me a "Configure now?" dialog with the message, "/dev/sda3 hasn't been configured. Do you want to configure it now?" I said OK. I told it to set the mount point to File System > Media > VMS. Then I clicked on the Assistant button and saw that the option was checked that said "The file system is mounted at boot time." I also checked the option that said, "Check file system at mount time" on the options dialog's Mounting tab. I didn't change any other options. When I checked OK to leave Assistant, I saw an error message in Terminal: "wrong fs type, bad option, bad superblock on /dev/sda3, missing codepage or helper program, or other error." I went back into Assistant and removed the "Check file system" option I had just checked. This time, when I left Assistant, I got Warning messages that said, "Unknown option: rw" and "nouser is not suitable for user" and "Unknown option: async." I clicked on the "Set defaults" button in SDM and then clicked Apply. This produced no additional Warning messages in Terminal. Trying once more, I just went into Assistant and immediately executed, and this did produce the same Warning messages, plus an additional one that said, "Unknown option: defaults." I tried just emptying out the Options box altogether in SDM. Then I clicked Apply. I did the same with the other ext3 partition that was not yet mounting automatically. I restarted the system.

It occurred to me that I may not have restarted the system previously, but may merely have logged out and logged back in. Ubuntu 9.04 seemed to require two steps to reboot, and it seemed that I had forgotten to take that second step last time around. This occurred to me right around the time when I tried to restart the system and found that it froze with a black screen. Evidently my fstab file was not presently in an acceptable form. I punched the computer's reset button and rebooted with the Ubuntu installation CD, chose the "Try Ubuntu" option, and edited fstab as above. (Note that there's an fstab on the CD too; make sure you're editing the one on the hard drive.) I saw that I had failed to add the preferred mountpoint for one of my ext3 partitions: it said "/media/sdc5" instead of "/media/CURRENT." I fixed that and rebooted without the CD. This time, the system booted OK. But those two ext3 partitions were still not automounted.

In File System > media (i.e., /media), I noticed that there was a mount point for the VMS partition, but it had nothing in it. I typed "dir" to make sure there was nothing there, and then typed "sudo rm -r VMS" to delete it. I also deleted the "sc5" mountpoint mentioned above. In File Browser, I clicked on the Computer button at the top and then double-clicked on each of these two partitions (i.e., VMS and CURRENT) to create mountpoints (i.e., /media folders) for them. I tried rebooting again. They still weren't automounting, and the mount points I had created for them were gone, as I should have expected. Incidentally, at this point I discovered that the custom was apparently to mount fixed hard drives at /mnt, and use /media for removable hard drives.

About this time, I discovered that I had commented out the lines added by SDM (i.e., I put # signs (also called hash marks) in front of each of those lines). I forgot. I had done that to troubleshoot fstab, and then didn't go that route after all, and forgot to remove them. So I removed the hash marks now and rebooted. But that wasn't the solution. I re-ran SDM, went through more or less the steps described above, and rebooted. This time, it worked: the partitions were automounted, and their contents were visible. Not sure exactly what was different this time, but something was. So I guess the conclusion is, if it doesn't work in SDM the first time, tinker around for a while, reboot a couple of times, try SDM again, and reboot.