Norton Ghost Error - Error EBAB03F1

Error EBAB03F1: The requested operation could not be completed due to a file system limitation.

 

This problem has been occurring when I try to run a back up of my C Drive (including verification). I do not have the problem when running a back up of my D Drive. No changes have been made to my system. i am running Windows 7 Home Premium. The back ups are run to an external hard drive attached to my laptop via a USB 2.0 cable.

 

I ran chkdsk on my C Drive and restarted the system with no effect on the problem.

 

I have not been able to run a back up of my C Drive for a couple of days.

I think the error is talking about the destination drive.

What kind of file system is on the destination?  If it's FAT32 it will have a 4GB file size limit and you will need to split the image into smaller pieces.

Did you also run a chkdsk on that drive as well?

Dave

The external destination drive runs NTFS as well. My next step is to run a chkdsk on the destination drive. What's strange however, is that the back up of my D Drive also goes to the same external hard drive, although to a different directory. I have also turned off the verification of the back up of the C Drive to see if this does anything.

If chkdsk doesn't do anything, you can try running a manual "one time backup" into the same folder the D drive backs up into.

If you still get the same error, try running it onto an internal drive.  You should at least be able to tell if the problem is the destination or the source.

 

Edit- Make sure it's not a permission or ownership problem as well.  Check to see that the folder has full read-write permission for everyone.

Ran a chkdsk, and changed the directory where the back ups go to. a manual back up worked fine, but the next scheduled back up crashed witht he same issue. None of my other back ups crash, nor do back ups of my C Drive crash when directed to a different physical external drive. I will try turning off the drive in question and then turn it back on. I'm also going to try and set up a new back up job for the C Drive.

 

Permissions aqnd ownership should not be an issue, as this is a straight external USB drive connected directly to the laptop, and back ups ran fine until late last week.

Still having the File System Limitation problem with only my C Drive back up. I do daily back ups of 2 additional drives to the same external hard drive with no problem. Back ups of the C Drive to a different external drive also work fine. I can find n erros on either my source internal C: hard drive or the external USB drive. I am at a loss as to how to resolve this problem. Does this sound like an issue with the USB drive?

Are your C and D drive backups in the same backup job or different jobs?  What is the name of the image that is created?  Go to the following:

HKLM\System\CurrentControlSet\Control\FileSystem

What is the value for NtfsDisable8dot3NameCreation? 

 

Ended up swapping in a different external drive where the back ups are going to. So far no problems noted.

 

To your question. the back ups were on separate jobs, and to different directories on the same external drive. Back up images are named:

 

MARTYLAPTOP-PC_C_Drive013.v2i for the C Drive and MARTYLAPTOP-PC_D_Drive013.v2i for the D Drive.

 

These are always the names used. It wasn't until a few weeks ago I started having problems doing a daily back up of the C Drive on this particular external drive. I was (and am) running a separate weekly back up of the C Drive to a second external drive with no problems. Note that I always run full independent images of my drives and not incrementals.

 

The Hexadecimal value for the key you inquired about is 0.

Glad to hear that swapping out the drive worked.  Initial feeling was that it was related to the filename, but it must have been something else.  I'm surprised chkdsk didn't find any problems.  Where you running chkdsk /r? 

Yes, but no errors were found. The strange part of this was that it was only the back up of the C Drive that had the problem.

It may have been a lower level problem then why chkdsk could find. Sometimes using low level disgusting from the manufacturer can be needed. At this point it should be moot though as you did find a workaround.