Lock when using io.Copy in a goroutine

I have a slice (filesMeta) containing a large number of "FileMetadata" structs. I also have another slice (candidates) containing the index of some of those structs. What I'm trying to do is modify the filesMeta slice to add an md5 hash but only for the elements which indexes are in the candidates slice.

I'm using goroutines to parallelize the work but the io.Copy part is causing a lock and I don't understand why.

This is the code:

for i := range candidates{
    wg.Add(1)
    go func(i int) {
        defer wg.Done()
        filesMeta[candidates[i]].Hash = md5Hash(filesMeta[candidates[i]].FullPath)
    }(i)
}
wg.Wait()


func md5Hash(filePath string) string {
    file, err := os.Open(filePath)
    if err != nil { 
        panic(err) 
    }
    defer file.Close()

    hash := md5.New()
    if _, err := io.Copy(hash, file); err != nil {
        panic(err)
    }
    hashInBytes := hash.Sum(nil)

    return hex.EncodeToString(hashInBytes)
}

Thanks!

Edit: One more detail, it doesn't lock when the files being hashed are in my SSD but it does when the files are on a fileshare.

Edit2: I noticed I forgot to pass the wg, the code now looks like this (still getting the same error):

for i := range candidates{
    wg.Add(1)
    go func(i int, wg *sync.WaitGroup) {
        defer wg.Done()
        filesMeta[candidates[i]].Hash = md5Hash(filesMeta[candidates[i]].FullPath)
    }(i, &wg)
}
wg.Wait()


func md5Hash(filePath string) string {
    file, err := os.Open(filePath)
    if err != nil { 
        panic(err) 
    }
    defer file.Close()

    hash := md5.New()
    if _, err := io.Copy(hash, file); err != nil {
        panic(err)
    }
    hashInBytes := hash.Sum(nil)

    return hex.EncodeToString(hashInBytes)
}

MarcoLucidi was right, I was opening too many files at a time. I limited the number of concurrent goroutines and now it works fine.

When reading from external storage, especially over network, it happens that the read can hang. I recommend that when you read files over networked drive, read just one at a time. I understand that this kills parallelization ability, but we cannot pretend same reliability over networked drives as we do about local ones.

Edit I proposed above solution because there are many network parameters which affect the performance over networked storage devices like: traffic, transmission speed etc. I remember once that I used a drive over network to store a Unity project. One day Windows Explorer started to crash because Unity was using too many files. I am sure they were not millions. Based on that I supposed that it was unlikely that this was happening due to the high number of goroutines. I proposed processing 1 file at a time taking into consideration the case when it may happen that files are big(over 50 GB) which may crash the communication with the network storage provider.