This looked strange to me, and I had expected, that the sharedfolder entry has to be deleted manually first. Otherwise there would be an orphaned reference in the sharedfolder entry to the mntent, wouldn't it. Therefore I asked to have a look again, if you really meant the mntent entry.
I hope this clarifies my question and my mentioning of "one level of hierarchy missing". By that I meant that I expected, down the hierarchy, before the mntent entry is deleted, the sharedfolder entry has to be deleted.
The orphaned sharedfolder entry to mntent doesn't hurt anything. The orphaned mntent entry will cause an fstab entry to written and potentially cause the system not to boot. Either way, I remove both entries at the same edit time.
If you make a backup of config.xml before trying these things, there is very little risk. Sorry for not being clear on my explanation.
Sure. I did not want that drive to fail, however. And I guess it happens to people now and then.
Yes, I know that. I didn't say you wanted the drive to fail. I was just telling that it is hard to write code to do the right thing when the failure is very unexpected leaving the system in a weird state. As flmaxey found, normally it works. I wouldn't waste your time trying to figure out why it didn't work on your system.
lmaxey obviously had killed the last disk he added. My died disk probably was not the last one I added (although I cannot be totally sure of that). Also I had ntfs. And I was using the root of the filesystem for sharing (which sometimes is not considered best practice).
Neither of these caused the issue. ntfs and the last disk are treated exactly the same as the other disks.
I saw something like "sharedfolders-elements.mount" and wrongly interpreted this as: hmm, here the elements (?) needed for shared folders are mounted (?).
Every sharedfolder gets a bind mount to /sharedfolders/[SHAREDFOLDER_NAME]. When you drive failed, this bind mount was still around causing an issue because it depended on the failed drive being mounted.