Digi is working on version 6 of XCTU that runs on Mac OS X. Get it here:

http://ftp1.digi.com/support/utilities/40003027_1P.dmg

I’ve been using it on Mountain Lion and it works fine for me, but I’ve only begun to test it out.

I’ve had the need to append pages to PDFs encoded with DRM. A great tool for removing DRM one file at a time is a service called pdfclean for OS X, an installer of the command line utility included with mupdf’s MuTool clean. I successfully installed and used the service under Mountain Lion and found it effective. Thanks, be3n!

For macOS Sonoma and later, be3n’s tool works as an Automator app, just drop an encrypted .pdf on it. I’m having some trouble with it removed the encryption under Sonoma and am checking with be3n on a potential solution. Right now, when pdfclean attempts to remove encryption on a .pdf, it makes a new file that takes the form “old_file_name.pdf.broken” – removing “.broken” allows the file to open, but the encryption is still there.

My beloved Ibex Commuter Knickers are wearing through. Say it ain’t so!

This is the right butt cheek in a close up.

This is the right side from further away.

This is the left side further away.

This is the left side close up.

I normally don’t have a use for a password cracking application like John the Ripper, but a family member was having problems logging in to their Mac and they couldn’t remember what password they were using for the keychain. I decided to give John the Ripper a try and I’m glad I did. It picked the password for the keychain in about a minute using its built-in dictionary. If you get in a similar bind, the following worked for me running Mountain Lion Server.

The family member was remote, so they zipped up the login.keychain file and sent it to me. I moved the file to my local machine running Mountain Lion Server, but this should work on Mountain Lion, Lion, Snow Leopard, and maybe further back… I downloaded a jumbo build of John the Ripper, moved the login.keychain file into the same directory as the “run” directory of the downloaded JtR, and ran the following commands from JtR’s run directory with Terminal.app:

./keychain2john login.keychain

(running keychain2john spews out a few lines of characters, copy all of the lines to a .txt file and save it to the JtR directory – I copied keychain2john’s output to “clwlogin.txt”) and then I ran the following command from Terminal:

./john -i=all clwlogin.txt

While the command above is running, you can press “enter” and see JtR’s status. When JtR picks the password, it will automatically throw it up on the screen followed by a question mark in parentheses. At this point, JtR will keep running to look for more passwords, so I press Control-C to force it to quit. Success!

I recently upgraded to iLife ’11 from iLife ’09. When I attempted to fire up iPhoto, I was prompted to upgrade my library. I accepted, but not more than a few seconds into the upgrade, I was greeted with: “Unable to open this Library”.

To get around this, fire up Terminal and do the following:

Type “sudo chown -R yourusername” (replace yourusername with the username on your Mac), press the space bar, drag your iPhoto library file from the Finder to the Terminal window, and press return.

Repeat the following process with these commands (enter the command, press space, drag iPhoto library to Terminal and press return):

sudo chmod -R -N

sudo chmod -R u+rwX

I recently migrated data from an Active Directory user account to a new user account, due to a bungled unbind from the Active Directory. Inside the new user account, I was able to import the login.Keychain, but the System.keychain was read only. I’m not sure if this is the correct permissions for the System.keychain, but I fired up Terminal and ran the following:

bash-3.2# sudo chmod 644 System.keychain

The following error message was repeated several times in Console on my aging G4 iMac running Leopard 10.5.8:

7/8/11 9:31:22 PM com.apple.AppleFileServer[8123] MDSChannelPeerCreate: (os/kern) invalid argument

This error appears to be related to permissions of “.feseventsd” located on the root directory of your boot drive. To fix it, quit file sharing by unselecting it in the “Sharing” preference pane, fire up “Terminal.app”, and enter the following at the prompt:

www-schwie-com:/ brad$ sudo chown -R root:staff .fseventsd
Password:
www-schwie-com:/ brad$ sudo chmod -R 770 .fseventsd

After these changes are made to the .fseventsd file, go back to System Preferences and turn file sharing back on under “Sharing”.

My Mac runs 10.6.6 and has a machine account on the Active Directory at work. Today at work, I was in System Preferences->Accounts->Login Options and, by complete accident, I unchecked “Allow network users to log in at login window”. What ensued was a waste of time, so I hope this saves you time, should the same happen to you (I posted a bug report with Apple today and I hope it is resolved in 10.6.7 or Lion).

After unchecking the box, the spinning beachball of death immediately came up and I was forced to restart my unresponsive MacBook Pro. When it came back up, I couldn’t log in to any of the accounts on the MBP, admin or not, network or local, even the root account. I freaked out and tried to reset my passwords by booting the Snow Leopard DVD and then I reinstalled Snow Leopard, but none of this helped!

Eventually, I happened across Brian Keefer’s solution.

To summarize his post, fix things by booting your Mac to the Login Window and in the username field, enter “>Console” without the quotes and press enter. Your screen will go dark for a few moments and then you’ll be prompted for your username and password. Enter credentials that use to work and you should be able to successfully authenticate. Now fix the problem, by using the line below with your own username and password substituted:

dseditgroup -o edit -a localaccounts -u yourusername -P yourpassword -T group com.apple.access_loginwindow

Repeat the command above for any other user accounts that you are not able to log in with. Now type in “reboot” and you should be able to log in as you use to.

When I wish to start over with a fresh install of WinXP that I keep around (whenever Windows XP gets fouled up and I want to start over), I create a new profile and import a stock .vdi I keep around. When I attempt to add the stock .vdi to the profile, Virtualbox freaks out with a UUID error saying it “failed to open a session for the virtual machine” and “UUID does not match value”. Get around this by going to File->Virtual Media Manager…, delete the .vdi from the list, add it back in, and then go in to the Machine profile and re-specify the .vdi.

For too long, Time Machine hasn’t been working on my Mac Pro running Mac OS X Server 10.5. Whenever I tried to enable it, a dialog with “Preparing…” would come up, but the backups would never execute. I believe this occurred after I did a restore one time. Anyway, Time Machine backups are now working again after I performed the following in numerical order:

1) Turn Time Machine off (by opening Time Machine’s Preferences…)
2) Trash the com.apple.TimeMachine.plist in /Library/Preferences
3) Restart your Mac
4) Full Spotlight reindex of the Macintosh HD (do this by dragging your hard drive into the privacy window of Spotlight’s preferences or by executing the shell command “sudo mdutil -E /”.
5) Added a bunch of folders to the “Do Not Backup” list in Time Machine
6) Turn Time Machine on