You can't do it.
Master-detail follows the "all or nothing" philosophy.
All users who can see the master record (account) will be able to see all detail records (meetings). If they'll have right to edit - they'll be able to edit. (Well, of course assuming the Read & Edit checkboxes are selected on the profile but you get the idea). Etc. Simple really.
When you convert lookup to master-detail relationship these things happen:
OwnerId
field disappears. This has some quite interesting impact on the business logic:
- can't assign the records to queues
- SF can't automatically assign them to current approver in approval processes (this doesn't seem like a big thing until the current approver needs to be able to edit that record to fix some data but the record is readonly for him; means some custom apex-managed sharing is needed to let him modify when he's the approver, revoke it when he's done...)
- all list views that relied on "My (meetings)", "My team's (meetings)" go bananas
- same with reports
- all sharing rules disappear
Meeting__Share
table disappears too.
(Note that it's not the only situation where sharing rules & Meeting__Share
will be invisible. Same happens if the object's Organization-Wide Defaults are set to "Public Read/Write").
So - you need to get back to design phase. Do you need the Master-Detail in this relationship (rollup summaries, cascade delete, automatic sharing of detail records inherited from parent) or you need more fine-grained control but then you'll have to worry about all the components manually.
If you wish to stick to the M-D concept - write Apex-managed sharing code to share the master (Account) and maybe add some validations or something if you don't wish them to edit the accounts...