You need to be accurate when you define the use-case subject, that is the system under consideration.
Use-cases are mostly applied to software, for example a library software. But Ivar Jacobson, the inventor of the use-cases, also wrote a book about applying use-case to business analysis in which the system under consideration is used for departments or even companies. And this makes your question very ambiguous.
What's the problem with your question ?
suppose the system is : Library
What does this mean ? Is the library the library the building ? Is the library the facility and its books ? Or do you mean the library as an organisation ? The correct answer depends entirely on your definition !
As we are here on "software engineering stackexchange", the other contributors all understood that the library was the library software. But this does not match your statement. So none of the other answers is right, despite they are insightful if you would have said that the system is the "library software".
What is the right answer ?
library is the facility and the books, the
librarian would be external to the library, and he/she would be an actor. For the use-case
borrow a book, the primary actor, the one who would expect the most value from the interaction, would be the
member. But the librarian would be involved in the use-case. He/she'll be a secundary actor.
library is the organisation or the company, the
librarian would be part of that organisation (human resource) as well as the facility and the books (material resources). The only actor would be
member. Perhaps a secondary actor could be the local authorities if the library has to fine you because you don't bring the book back ;-)
library is in fact the software use by the library, the primary actor of the
borrow book use-case would be the
librarian, since he/she would interact with the software, whereas the
member would interact with her. Unless it would be an ultra-modern library, where users could self-register their borrowings, the exit door opening only if all the detected books are registered ;-) Anyway, for the software case, you could have a look at all the other answers which are all very relevant.
Now in this last case, the
member does not interact with the system. According to the UML specs, the member is therefore not an actor: