Should there be one or multiple XXXRepository instances in my system, with DDD?

Should there be one or multiple XXXRepository instances in my system, with
DDD?

There's something that has been bothering from my DDD readings. From what
I've seen, it seems as if there is only repository instance for each given
aggregate root type in my system.
Consider, for instance, the following imaginary situation as an
abstraction of a deeper domain model:

When coding in a "standard-style" I'd consider that each Owner in my
system would have its own collection of cars, so there would be an equal
number of Car collections (should I call it Repositories?) as there are
Owners. But, as stated previously, it seems as if in DDD I should only
have one CarRepository in the whole system (I've seen examples in which
they are accessed as static classes), and to do simple operations such as
adding cars to the Owner, I should make use of a domain-service, which
seems to be, for the simple case, not very API friendly.
Am I right about only having one CarRepository instantiated in my system,
or am I missing something? I'd like to strive for something like
public void an_owner_has_cars() throws Exception {
Owner owner = new Owner(new OwnerId(1));
CarId carId = new CarId(1);
Car car = new Car(carId);
owner.addCar(car);
Assert.assertEquals(car, owner.getCarOf(carId));
}
but that doesn't seem to be possible without injecting a repository into
Owner, something that seems to be kind of forbidden.