SD fails - "Unable to copy extended attributes from directory /private/mnt"

[Pablo Pablo]

I'm running Leopard and have an external firewire drive with two partitions. I'm using one for Time Machine backups, and I want to use the other for Super Duper! backups. Both partitions show up in finder and the desktop.

My problem is that the SD! back up fails with this error.

Unable to copy extended attributes from directory /private/mnt. Operation not permitted.

I've used SD! on Tiger before now and haven't had this problem - can anyone help?

Thx..
PP

[dnanian]

Please send your log into me at the support email (use "Send to shirt pocket"). Thanks.

[Pablo Pablo]

Originally Posted by dnanian

Please send your log into me at the support email (use "Send to shirt pocket"). Thanks.

Thanks for the reply, Dave. I got round the problem by excluding the /private/mnt folder (which I couldn't access from Terminal).

I think I might have sent the log already, but I'll send it again anyway.

PP

[southside]

Hi,

I just upgraded from TIGER to LEOPARD (on my Powerbook G4 1.25 GHz, 3 years old and still kickn' machine) and want to make a SuperDuper image backup. I am using the LEOPARD compatible version of SuperDuper. I have loaded all the Apple upgrades on my LEOPARD OS (10.5.2 and a video upgrade and a security upgrade, as well as other application upgrades that were necessary per Apple upgrade)...

I am having the same problem that this thread is about. When SuperDuper tries to access the files my Little Snitch application warns me that mount_nfs is trying to connect to 192.168.0.71 on port 111 (which is used by tftp, a very insecure protocol - ftp without login/password)... and it tells me /sbin/mount_nfs is the file that is causing the problem. I think that with TIGER I was able to disable this file - forget how - to get around the problem and at the same time shore_up a possible security hole in the OS...

At any rate,
appreciate any light you can shed on this - and associated fix/workaround,
southside_bruce

[dnanian]

Please send the log from this run into support, southside -- I'd like to take a look at exactly what you're seeing.

[southside]

Dave,

I tried, and I tried and I tried (think three or more times) to back up the chock full o' files 80 GIG internal HD to a partition on my relatively new Lacie faster than all getout, FIREWIRE 800 500 GIG external HD...

Tried to use a script that ignored /private/mnt - but SuperDuper still tried to access the directory... And when you try to cd to mnt - you get that whacky automount to 192.168.0.71 nfs command stream going (port 111, etc)... I had deactivated my Norton AV autoscan/etc... but that didn't work...

so, at around midnight, I had gotten out of bed and checked on the backup - and it had failed AGAIN... I decided to do some investigation on the Web and found a dude's blog:

http://www.felipe-alfaro.org/blog/20...er-and-finder/

where he discussed what was happening - kinda/sorta...

I decided to take action - and as root, mv'd the plist file in:

/var/db/dslocal/nodes/Default/mounts

to a different filename... I wasn't able to cd to /private/mnt anymo, after that
bold (and probably stupid in the big scheme of things) move...

With TIGER there was another automount file (forget where) and I was able
to comment out a call to /private/mount_nfs - something like that (I forget
what_all I had done), but that method worked as well - and wasn't about
moving a plist file (whatever a plist file is - I know not a lot about Mac OS/X,
although I know quite abit about Unix - as I am a software_dude by trade)...

AnyHOOT - the change to the filename did the trick. I ran SuperDuper one more time late last evening, without the script that ignored that directory... And the backup worked. Took 4 hours 41 minutes, but I was able to boot off of the partition after the backup. I am also using Leopard's time machine to do back ups, but I ABSOLUTELY LOVE the bootable image backups that SuperDuper creates. Not sure how I lived without this product for 2.5 years or so - hoping for the best all that time, and damn lucky that the worst didn't happen...

thanks Dave, and the rest of the SuperDuper development team - you guys ROCK!!

southside_bruce (live, from Bangkok, Thailand)

[JoBoy]

When something is trying to "call home," Little Snitch alerts you. You have the option of denying permission until the present application quits or denying permission "permanently." When you deny permanently, Little Snitch will not launch a window that interferes with the backup. When you run SD! the next time, no window will open to interfere with the backup.

In this case, "permanent" doesn't really mean forever. You can open Little Snitch and easily find the permanent rule that you created and delete the rule if, later, you should discover a need to do so.