We're using rsync to copy files into an existing directory structure which includes symbolic links. After the copy, the permissions on the symlinks are changed to 000: "l---------". To the best of my understanding, this shouldn't even be possible. What's happening and how can we stop it?

A symlink is basically a tiny file with a filename in it. I don't think that its permissions matter anyway. It's an indirect reference to a file, and either you can open that file or you can't.

Incorrect. It is preventing us from following the link.

Because the files the symlinks link to don't exist anymore. Symlinks don't have permissions. Dead ones do. The files the links refer to are no longer in their original location. Make the symlinks relative rather than absolute.

Don't be so quick to brand a very-correct answer as "incorrect" merely because you do not yet understand it.

First of all, remember that there are two kinds of links: "hard" and "soft" (or "symbolic"). The latter is what I was referring to. A "hard" link is an additional reference to the same underlying file-system data structure (the so-called inode), which will not actually go-away until all of the hard-links are gone. But a "symbolic" link has no skin in the game. If the file(name) to which it refers is moved or changed in any way, the symbolic link becomes "broken" and can no longer be followed. The symbolic-links are not tracked and will not be updated in that case.

"Symbolic links" are, just as I/we said, "tiny files with file-names in them, flagged to the filesystem as being 'a symbolic link.'" The filesystem will silently follow that chain of filenames ("de-reference" the symbolic link ...) a certain number of times until it either: finds a file, finds a circular reference, or gives up. It will speak to you throughout in terms of the symbolic-link name, not its so-called "target," since the link is what you asked to open and the target is malleable.

You can't "protect" a symlink, and you can't keep the curious from finding out the name of the eventual target. Permissions for "hard" links are, IIRC, actually maintained at the inode level.

I understand the situation better than you do. Symbolic links definitely do have permissions of their own apart from the target file, whether or not it exists.

I still don't know what is causing the symlinks to be created with 000 permissions, but I found out how to fix it. "chmod -h".