From what I gather, taking into account your other email as well, there
are two separate things going on which may or may not be related:

1) The (now open) filesystem isn't being mounted where it should as per
fstab

2) Even then, there appears to be a bogus 'private' parent directory:
/run/media/private/<uid>/<volume> as opposed to /run/media/<uid>/<volume>

On 11/06/2020 23:17, Dale wrote:
> This is my fstab entry:
>
> UUID="7f0cf585-57c8-4a50-808b-987fc13ceee0"
> /home/dale/Desktop/Videos/Private  ext4 defaults,users 0 0
> ...
> You notice anything off about that?  I make a error somewhere?  Miss a
> option maybe?

fstab doesn't like quotes. The correct syntax would be:
UUID=7f0cf585-57c8-4a50-808b-987fc13ceee0

Re (1) above, given that /etc/conf.d/dmcrypt is only used by the dmcrypt
service through OpenRC its contents are irrelevant when using KDE. So,
from the perspective of DN updating fstab with the correct syntax should
be a two birds, one stone solution to both (1) and (2).

Unless your encrypted volume is always connected to the system and you
would like it to be automatically unlocked (via means of being asked to
enter your password), there is no need to enter anything into
/etc/conf.d/dmcrypt and you can leave the file blank/commented out.

Re (2), frankly, I have no idea but I'm curious as to where that
"private" parent directory might come from. The only possible source for
this that I can guess is from your entry in /etc/conf.d/dmcrypt in the
value for "target":

> ## 3TB private drive external
> target='private'
> source=UUID='107be33c-b31c-44b8-b4e7-400ee19fb440'

While this should only affect the name of the block device created under
"/dev/mapper" it seems too much of a coincidence that the bogus parent
directory bears the same name. I've tried to reproduce your set-up but I
still don't get such a parent under /run/media. Perhaps you can try
changing the value to something else and see if it creates a directory
with the new name? If so, this would confirm the theory, but it still
shouldn't be doing that. At least it would be a starting point for
diagnosis, if it's worth going into that at all.

Also, note that, as I mentioned, when mounting a crypto container
through KDE DN or Dolphin your dmcrypt config is irrelevant and
disregarded. You should hence expect upon opening the container to have
the filesystem's block device appear as "/dev/mapper/luks_abcd1234".

- Victor