If the threads only need to grab a couple vecs at the beginning of their work there's nothing wrong with also wrapping the hash map in a lock. You probably also need to wrap the inner RwLock<Vec> in an Arc so you can clone the Arc and then surrender the outer lock before starting the thread's work.
If the threads never need to mutate the map itself (to add or remove vecs) you can just add an Arc on the HashMap instead of another RwLock.
Do you mean "mutable access" when you say ownership? Because locks don't give you ownership, they only allow you to get mutable access from a shared reference.
That's not true, you can have the outer RwLock which is locked for writes when inserting/removing from the HashMap and for reads when you want to only access the Vecs. If you want to mutate the inner Vecs then you can lock the outer RwLock for reads and the inner RwLock for writes, thus allowing multiple threads to access different Vecs at the same time. The only problem with this approach however is that the threads that want to insert/remove from the HashMap may starve depending to the OS RwLock's policy.
In the end, I would suggest you to use a concurrent hashmap, for example dashmap.