Even though the root cause of this bug is a JVM bug, I think it is possible to fix it in Derby.
The failing call is to Files.getFileStore(Path). We only need the FileStore instance in order to check if the specific FileAttributeView is supported on the file system (by calling FileStore.supportsFileAttributeView()). But this information can also be found by checking if Files.getAttributeFileView() returns null. Since we already call getAttributeFileView() to get the view, the calls to Files.getFileStore() and FileStore.supportsFileAttributeView() are redundant and can be removed.
The attached patch, d6410-1a.diff, removes the redundant calls. With the patch, I'm able to start the network server on a subst drive without getting an error, and the files created by the server instance have restricted file permissions. I've also successfully run RestrictiveFilePermissionsTest on a subst drive with the patch.