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
signature.asc
Description: OpenPGP digital signature
