Unlocking PDFs

I was working with PDF files.  For purposes of reading them onscreen, I found it helpful to go into Adobe Acrobat and crop off most of the white space around the text.  This would allow Acrobat's page view to show the text in a larger size, making it easier to read.  I also sometimes liked to add bookmarks.  And for many PDFs, I would add a comment balloon on the first page, citing the URL, bibliographic information, or other indications of where the PDF came from, for future reference.

None of these things were possible when the creator of the PDF would password-protect it.  I was not sure why people would do that.  Most of them didn't, but there was the occasional exception.  Maybe they feared that someone would go in and change their wording.  I had never seen or heard of that, in my years of working with PDFs.  It did not seem like a realistic concern, for purposes of the kinds of PDFs that I was working with.  Its drawback was that it made it irritating, difficult, and for some purposes impossible to work with what they had written.

To get rid of the password, so that I could make adjustments like those described above, I did a search for appropriate freeware.  The first site that came up was an About.com review of a handful of tools that were supposedly capable of unlocking PDF files.  Some of these programs could actually figure out what the original password was, though apparently that could take hours, days, or longer, depending on how complex the password was and what level of security was used.  It was evidently faster for a program to just break the password without trying to figure out what it was.

Among the tools listed in that About.com review, I had long used Freeware PDF Unlocker.  Unfortunately, I was not able to install the version available at this point (1.0.4) in 64-bit Windows 7, even though the About.com webpage said that I should have been able to do that.  The solution to that problem was to run it from within a Windows XP virtual machine (VM), created automatically by Windows Virtual PC.  Once I had installed Virtual PC, I had to go into it, open a Windows Explorer session (Start > Run > explorer), copy the Freeware PDF Unlocker installation program to Local Disk C, and install it from there.  I had to do that copying inside the VM because, of course, the virtual drive C used by Virtual PC did not actually exist on a hard drive:  it would not appear in Windows Explorer in Windows 7, outside of the VM. I had to install it from Local Disk C, inside the VM, because the VM would not install programs located on real drives.  Once it was installed, Freeware PDF Unlocker put an icon on the desktop in the VM.  I could then drag a passworded PDF from Windows Explorer, drop it on that icon, and get a PDF of the same name, with "_noPW" added at the end of the file's name.

Needless to say, it was a bit of a hassle to start a Windows XP VM, find the PDF in a Windows Explorer session inside the VM, and drag it over to the icon.  Freeware PDF Unlocker also was not able to unlock some PDFs with more advanced security, imposed by people who were desperate to insure that nobody would ever be able to change their words -- adding, perhaps, a faux testimonial about the author's positive experiences in having sex with animals.  I mean, that was certainly something to be worried about.  If I was going to continue with my work of inserting such comments into random PDFs, I was going to have to find a better PDF cracker.

The first relevant tool on the About.com list was Guaranteed PDF Decrypter (GuaPDF for short).  I ran it on a PDF that Freeware PDF Unlocker hadn't been able to unlock.  GuaPDF gave me a message stating that it definitely could unlock the file, but unfortunately the file was too large for the free version, so I was going to have to buy the paid version.  That was a possibility, but I decided first to continue down the About.com list.

The next option on that list was FreeMyPDF.com.  This was an online service.  I had to upload my PDF and let them do their magic on it.  I then spent a minute or two watching the charming RevolverMaps image, on their webpage, that showed how people around the world were using FreeMyPDF at this very ... well, recently.  I didn't snap out of it until FreeMyPDF had downloaded the decrypted PDF back to me, a minute or two later.  Its print was a bit faded, compared to the original, but it looked like everything was there.  Acrobat wasn't able to OCR its pages until I first saved them as JPGs and then stitched them back together in Acrobat, producing a much larger file.  Then again, I didn't really need to OCR its pages.  They were already OCRed.  I did it just because the OCR process (or, in this case, reducing the gamma on the individual JPGs in IrvanView > File > Batch Conversion/Rename > Advanced, after first testing on a sample JPG in IrfanView with Shift-G) could sometimes improve the appearance of the text.

Anyway, FreeMyPDF had done the job, so that killed the incentive to look further down the About.com list.  But if the incentive had been there, the next candidate would have been PDF Password Remover Online.  This appeared to be another upload-download option, though apparently (according to About.com) accommodating a smaller maximum PDF size.  Another option:  PdfCrypt, a command-line tool.  There were a couple of other tools on the About.com webpage, but they seemed to be password retrievers and, as I say, would thus presumably be slower.

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.10: Error: Could Not Update ICEauthority File

When I was booting a new Ubuntu 10.10 installation, I got an error message, "Could not update ICEauthority file /home/ray/.ICEauthority." I clicked through that, checked Update Manager, and rebooted. The ICEauthority error message was there again.

Seeking answers to this problem, I ran a search and tried the suggestion to type Ctrl-Alt-F1 to get a text console. There, I hit Enter to get a login prompt. I logged in with my username and password, and this gave me a regular command prompt. I typed "sudo chown -R ray:ray .ICEauthority," where ray was my username. Then I typed "sudo /etc/init.d/gdm restart" to go back into the Gnome GUI. But the ICEauthority error message was still there. (From another post, it appears I could have just entered the chown command in Terminal, without Ctrl-Alt-F1.) People for whom this approach worked seemed to think that the problem was caused by opening a graphical (i.e., not purely text-based) program owned by root using sudo instead of gksudo. If that was relevant, it evidently meant I should have edited fstab by typing "gksudo gedit /etc/fstab." But was gedit a graphical program? Probably the better explanation was that my problem was caused by something else, and that this is why their solution didn't work for me.

Comments in another thread suggested that the problem might have been caused by an update, and also that the chown command (above) wouldn't work on an encrypted home partition. In a variation, I tried this:

sudo -i
chown ray:ray /home/ray/.ICEauthority
chmod 644 /home/ray/.ICEauthority\
exit

But this didn't do it either; the error was back when I rebooted. Somebody else said the problem had to do with changing passwords, and that was possibly relevant for me, so I went into System > Administration > Users and Groups and changed my user password, and also checked the box that said, "Don't ask for password on login."  But Ubuntu hung when I clicked OK; the circle icon (like the Windows hourglass, meaning "I'm working on it") stayed there for a couple of hours.  When I came back to the machine, I killed the dialog box and tried changing the password again, but it hung again.  I ran a search on that subproblem and tried the advice to kill that GUI approach and just type "sudo passwd [username]" in Terminal (my username was ray).  That worked.  So, back to the ICEauthority problem.  I rebooted, but no, the password fix was not the solution; the error message was still there.

Another suggestion was to make sure that the entire home directory belonged to the user (me).  That sounded like it might be on the money.  My impression was that moving around and copying this old /home partition could easily have screwed up the permissions.  So now, how to make sure I owned the whole /home directory?  In Nautilus (i.e., Places > Computer), I right-clicked on Home Folder > Properties > Permissions.  It said root (i.e., not ray) was the owner.  In Terminal, I typed "sudo nautilus" and, using the Tree (i.e., not Places) view (top of left panel), went to File System > home > ray > right-click Properties > Permissions and changed the permissions to me with full access.  I clicked on the "Apply Permissions to Enclosed Files" button, closed out of there, and rebooted.  Eureka!  That was the solution.  Done!