Now just wait a second and Finder should restart. If you’re lucky the drag and drop issue will have resolved. Restart Your Mac. If restarting the Finder isn’t enough, then restart your Mac completely. For some people, simply putting the Mac to sleep and waking it back up works.
OS X v10.5.1 and later include an application firewall you can use to control connections on a per-application basis (rather than a per-port basis). This makes it easier to gain the benefits of firewall protection, and helps prevent undesirable apps from taking control of network ports open for legitimate apps.
- Mac OS X Server v10.5 or later: 8080: TCP: Alternate port for Apache web service — http-alt: Also JBOSS HTTP in Mac OS X Server 10.4 or earlier: 8085–8087: TCP: Wiki service — — Mac OS X Server v10.5 or later: 8088: TCP: Software Update service — radan-http: Mac OS X Server v10.4 or later: 8089: TCP: Web email rules — — Mac OS X.
- Block ads in Chrome on the Mac Google's Chrome browser is a popular alternative for Mac users, and even though Google is a full paid-up member of the advertising fan club, it allows plenty of.
Configuring the application firewall in OS X v10.6 and later
Use these steps to enable the application firewall:
- Choose System Preferences from the Apple menu.
- Click Security or Security & Privacy.
- Click the Firewall tab.
- Unlock the pane by clicking the lock in the lower-left corner and enter the administrator username and password.
- Click 'Turn On Firewall' or 'Start' to enable the firewall.
- Click Advanced to customize the firewall configuration.
Configuring the Application Firewall in Mac OS X v10.5
Make sure you have updated to Mac OS X v10.5.1 or later. Then, use these steps to enable the application firewall:
- Choose System Preferences from the Apple menu.
- Click Security.
- Click the Firewall tab.
- Choose what mode you would like the firewall to use.
Advanced settings
Block all incoming connections
Selecting the option to 'Block all incoming connections' prevents all sharing services, such as File Sharing and Screen Sharing from receiving incoming connections. The system services that are still allowed to receive incoming connections are:
- configd, which implements DHCP and other network configuration services
- mDNSResponder, which implements Bonjour
- racoon, which implements IPSec
To use sharing services, make sure 'Block all incoming connections' is deselected.
Allowing specific applications
To allow a specific app to receive incoming connections, add it using Firewall Options:
- Open System Preferences.
- Click the Security or Security & Privacy icon.
- Select the Firewall tab.
- Click the lock icon in the preference pane, then enter an administrator name and password.
- Click the Firewall Options button
- Click the Add Application (+) button.
- Select the app you want to allow incoming connection privileges for.
- Click Add.
- Click OK.
You can also remove any apps listed here that you no longer want to allow by clicking the Remove App (-) button.
Automatically allow signed software to receive incoming connections
Applications that are signed by a valid certificate authority are automatically added to the list of allowed apps, rather than prompting the user to authorize them. Apps included in OS X are signed by Apple and are allowed to receive incoming connections when this setting is enabled. For example, since iTunes is already signed by Apple, it is automatically allowed to receive incoming connections through the firewall.
If you run an unsigned app that is not listed in the firewall list, a dialog appears with options to Allow or Deny connections for the app. If you choose Allow, OS X signs the application and automatically adds it to the firewall list. If you choose Deny, OS X adds it to the list but denies incoming connections intended for this app.
If you want to deny a digitally signed application, you should first add it to the list and then explicitly deny it.
Some apps check their own integrity when they are opened without using code signing. If the firewall recognizes such an app it doesn't sign it. Instead, it the 'Allow or Deny' dialog appears every time the app is opened. This can be avoided by upgrading to a version of the app that is signed by its developer.
Enable stealth mode
Enabling stealth mode prevents the computer from responding to probing requests. The computer still answers incoming requests for authorized apps. Unexpected requests, such as ICMP (ping) are ignored.
Firewall limitations
The application firewall is designed to work with Internet protocols most commonly used by applications – TCP and UDP. Firewall settings do not affect AppleTalk connections. The firewall may be set to block incoming ICMP 'pings' by enabling Stealth Mode in Advanced Settings. Earlier ipfw technology is still accessible from the command line (in Terminal) and the application firewall does not overrule any rules set using ipfw. If ipfw blocks an incoming packet, the application firewall does not process it.
There are not many things I miss from Mac OS 9. But there’s one that was really useful: the ability to test a hard drive surface. OS 9 disk formatter (I don’t even recall it’s name) had a “Test Disk” option that would perform a surface scan of the selected hard drive. That was awsome to test for bad blocks on the drives.
Unfortunately, that’s impossible to do with Mac OS X, at least with it’s built-in software. There are some commerical applications to do that (like TechTool Pro), but I get a little pissed off when I have to spend a lot of money buying a software that does a zillion things when all I want is surface scans, and specially when I could do it with the “old” OS and not with the new powerful UNIX-based one.
Well, Linux has the badblocks command that will do just that: test the disk surface for bad blocks. It’s a simple UNIX command, so I thought there must be a port of that to OS X (and, of course, I could try to compile it in OS X as last resource). After some googling, I found out badblocks is part of the ext2fs tools. And, fortunately, Brian Bergstrand has already done the port to OS X, including a nice installer.
The installer installs all the ext2fs stuff, including an extension that will allow you to access ext2fs volumes on OS X. As always, this is a somewhat risky operation. Personally, I avoid as many extensions as I can, because they run too close to the kernel for me to feel confortable. So, if possible, install it on a secondary OS (like an utility/recover system on an exteral hard drive, or so).
The badblocks command will be installed in /usr/local/sbin/badblocks, and it will probably not be on your PATH, so you have to type the entire path when using, or edit your PATH environment variable.
Dropping Blocks Mac Os Download
Usage is simple. First, run the “mount” command, so that you know the device names for the drives you want to test. You can obtain something like this:
arroz% mount
/dev/disk0s3 on / (local, journaled)
devfs on /dev (local)
fdesc on /dev (union)
on /.vol
automount -nsl [142] on /Network (automounted)
automount -fstab [168] on /automount/Servers (automounted)
automount -static [168] on /automount/static (automounted)
The internal hard drive is /dev/disk0 (note that /dev/disk0 is the entire drive, /dev/disk0s3 is a single partition). Imagining you want to test the internal hard drive you would type the command (as root):
badblocks -v /dev/disk0
This would start a read-only test on the entire volume. The -v is the typical verbose setting, so you may follow what’s happening. This will take a long time, depending on the hard drive you use. For a 160 GB hard drive, it took between 2 and 3 hours in a G5 Dual 2 Ghz.
I mention this because time is an important factor when testing hard drives! You should run badblocks on a known-to-be-in-good-condition hard drive, so that you can get the feeling of how fast (or slow) badblocks is. Later, if you test a possibly failing hard drive, and badblocks progresses notably slower, it will probably mean that the hard drive is in bad condition (even if it doesn’t have badblocks).
After running the command, you may get two results: your disk has, or hasn’t badblocks! 🙂 You will see many outputs of a successful surface scan, so I leave here an example of a not-so-successful one:
/usr/local/sbin arroz$ sudo ./badblocks -v /dev/disk0
Password:
Checking blocks 0 to 156290904
Checking for bad blocks (read-only test): 120761344/156290904
120762872/156290904
120762874/156290904
done
Pass completed, 3 bad blocks found.
This is the result of a test on a 160 GB hard drive with 3 bad blocks.