External backup - "cp: cannot create regular file" error

A conflict between the source filenames and the destination filesystem can cause your cannot create regular file error. If you are copying to a USB thumb drive, you are probably using the vfat or fat32 filesystem, which is subject to the usual Windows naming restrictions.

To observe this, try creating a file named :, which is a Windows reserved character.

$ cp /dev/null /path/to/dest/:
cp: cannot create regular file '/path/to/dest/:': Invalid argument

To see the Operation not permitted error separately, try creating a symlink without copying.

$ ln -s somesillysymlink /path/to/dest/symlink
ln: failed to create symbolic link '/path/to/dest/symlink': Operation not permitted

If you see these errors, that is likely the cause of your problem.

Likely the simplest approach is to create an archive that is free from the naming restrictions you have encountered, and also preserves symlinks. By default, tar and 7z preserve symlinks. zip preserves symlinks with the appropriate flag. Each of these can store files that have Windows reserved characters in their names. See also “How can I zip/compress a symlink?”

Replacing the vfat filesystem with something more Linux-friendly – such as ext4 – would alleviate your problem, but at the cost of reduced portability. Almost any Linux system would be able to mount the drive, but other common systems would require extra work. See “Creating ext4 partition from console” and the mke2fs manpage for details on the creation end of the process. See “How to read ext4 partitions on Windows?”, “How can I mount an ext4 file system on OS X?”, and “How do I mount Ext4 using OS X Fuse” if you need to move that drive to other operating systems.

cp -rv should at least tell you what file it's baulking out on.

The problem you're having sounds like you're copying a symlink (that is a file that just points to another) to a filesystem that doesn't support symlinks. There are three options for this:

• Turn your backup volume into a filesystem that accepts symlinks (eg reformat it from FAT or NTFS to EXT3 or EXT4). Might be a pain depending on how much data you've got there (that you might have to juggle while you do it).

• Just ignore symlinks and not copy them. This might break things if you try to restore as it'll be missing some files.

• Expand out symlinks so they contain a copy of the actual data. This takes up more space.

The first would be my choice but if you need the drive for another system that doesn't support EXTx volumes, that's an issue.

Whether or not the second two are realistic options, I'd run cp with its verbose flag to see what you're dealing with. If it's a single file, perhaps a plain copy would be okay, if it's not, and it's just a junky helper, perhaps omitting it would be okay.

But as a side note, most people seem to prefer using rsync to do backups. It has a whole lot of options that make it perfect for the job. You can read a version of its manpage here. It has various options (as outlined above) on how to handle symlinks.

See your dmesg. Usual problem is either filesystem problem or failing hard disk (and therefore filesystem problem).

You can umounting external disk and then running fsck. For example

umount /dev/sdb1
fsck -f /dev/sdb1

I just ran into the same problem (actually on Cent OS via VirtualBox) and the problem was permissions related. I had a shared directory with my local machine (a Mac on OSX Mavericks), attempted a cp and it balked on Protocol error. In my local machine I changed the owner of the directory to the regular user (me) (from root) and the group to something more generic than wheel. So, turned out to be a basic permissions problem.