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.

Ubuntu 10.04: Useless Mount Woes

I was using Ubuntu 10.04.  I had begun using Ubuntu in the belief that I would have a more logical computing experience than I had had in Windows, and in many ways that had been true.  But the whole realm of file permissions just baffled me, and once again it was causing me hassles and lost time.

This time, the problem had to do with what I might call "ghost mountpoints."  I had previously had my external USB drive (named DAILY) listed in fstab, for some purpose or other, but then it seemed that that had been causing a problem, so I removed it.  So now I had a new problem.  Apparently Ubuntu would just take it upon itself to create a nonexistent "mount point" in the /media folder, bearing the same name (i.e., DAILY); and if you unplugged and replugged the drive, it would not adopt the old one, but would instead create a new one, with an underscore appended to it.  So now I had /media/DAILY and /media/DAILY_ and /media/DAILY__ mountpoints, and when I tried to use scripts and such that would refer to plain old DAILY, they would not find it.

The problem, as it had now developed, was that I could not delete those old mountpoints.  They were all empty, but when I went to them in Nautilus -- to, say, /media/DAILY -- and right-clicked on it, the "Move to Trash" option was greyed out; and if I chose Unmount, it said this:

Unable to unmount DAILY
umount: /media/DAILY mount disagrees with the fstab

It said that because I had just now typed "sudo gedit /etc/fstab" and had revived the line that I had previously commented out, the one that provided for recognition of DAILY; and then I had typed "sudo mount -a" to mount the damned thing.  On the other hand, if I went to its sister, DAILY_, and tried the same steps, I got this:

Unable to unmount DAILY
umount: /media/DAILY_ is not in the fstab (and you are not root)

both of which were true.  But then if I typed "sudo nautilus" and went at it through the administrator's (root's) Nautilus, the Unmount option would do nothing, and the Move to Trash option would leave me with this:

Cannot move file to trash, do you want to delete immediately?
The file "DAILY_" cannot be moved to the trash.
Unable to trash file: Device or resource busy

But the Delete option would then give me this:

Error while deleting.
There was an error deleting DAILY_.
Error removing file: Device or resource busy

But what was it busy with?  There was nothing in it!  I did a search for that last error message and, sure enough, found a total of nine hits from the entire Google version of the Internet.  One source gave me the idea of trying "sudo umount -d /media/DAILY."  But I forgot the -d and that command just hung.  I killed that Terminal session and tried again, but it still hung.  I left that hang and tried the same thing with DAILY_.  That hung too.  Back at the drawing board, I tried the same thing but with -f instead of -d.  (This was what I had meant to do in the first place, but the smell of dinner had distracted me.)  Those hung too.

I found a tutorial on solving the problem on a jump drive, where you could just copy your files over to another drive and then delete directories etc.  I didn't want to have to do that with a 500GB external drive.  I tried rebooting the system without the external USB drive connected.  A disk check ran during reboot.  I also got a notice, during reboot, that DAILY was not connected; it noticed, now that I had it included in fstab.  When the system came back up, those DAILY, DAILY_, and DAILY__ entries were gone.  I wished there were a better way of getting rid of them -- it remained to be seen whether that problem would recur, now that DAILY was listed in fstab -- but at least a reboot and/or disk check had done it this time.