Thanks. I have added a section about `findmnt` to the page. I'll expand the section later.
Edit: It seems an adequate replacement for `df` and `mount`. Can it print a block device tree organized by device name like `lsblk`? I have skimmed the man page and not found options for it.
Ok, the df one works, so--assuming the mount ones work (I haven't checked)--I guess you are up to 2/3 and so "the majority": touché ;P. The lsblk one though isn't even close... I'm not sure whether you are trying to cover this with your parenthetical that the functionality isn't the same, but then I don't get why you are trying to slip it in that list.
The basic/key functionality of lsblk is that it shows me all the things that look like disks; which, to me, shouldn't include all of these squashfs mounts, but--very very critically--includes disks that haven't been mounted, as the whole point is that we are looking at block devices, not mount points, or we would be using mount instead of lsblk.
Another important feature of lsblk is how it then takes those block devices and builds them into a tree, showing me how the various layers of--again: potentially as yet unmounted--block devices are "built": I can see that this device isn't in a filesystem, but is being used by an md array which is then used by a bcache or (conversely) that this filesystem isn't just some opaque bcache but is a cache of an md array of some set of specific disks.
The findmnt command you provided thereby simply doesn't seem to do anything related to lsblk; again: you said it wasn't functionally the same... but then what are you trying to show me? I will note your findmnt version also doesn't even succeed in filtering all of the loopback disks, much less all of the random mount trash... 7:0 is just the first /dev/loop, but I have a giant pile of them (due to the stupidly slow and wasteful way Ubuntu insists on using squashfs). I don't think -S even supports something akin to filtering '7:*'?
(FWIW, I do thank you for at least causing me to think about my lsblk usage, as I usually hated how the tree was to-me inverted and I was going to say I'd love to have a tool which didn't do that... but after decades of using lsblk I finally looked at --help and it turns out I can use -s to get the output I actually want, so I am amazingly happy! findmnt definitely isn't a useful alternative, enough.)
The block post is titled "Clean mount lists in Linux" not "Clean block device lists in Linux". I was demonstrating that findmnt can filter the source based on MAJOR:MINOR as a tangential, there was no attempt to "slip" anything in, hence the disclaimer.
You are correctly pointing out that it filters only the first loop device and doesn't support globbing. lsblk is clearly the better suited tool for the job you are describing and the reason I said "majority" in my first comment.
That's the article's title, but the actual content of the article is about: 1) df, 2) lsblk, and 3) mount. And yes: I clearly caught that you said "majority", as my first comment was about how you only seemed to have 1/3... but, now, showing -D for the df functionality (which was you showing me wrong, absolutely), I did agree that you have hit the majority (2/3). Adding the lsblk one continues to confuse me as to the intent.
(FWIW, I frankly just didn't like how you flippantly came in and off-handedly dismissed the article without much explanation and by redirecting people to a Linux-specific tool that has a million options that you apparently still have to configure. I found the article quite valuable as it somehow never occurred to me to try to get these tools to filter these crazy Ubuntu devices, and it felt as if--honestly still kind of does--you were viewing the article extremely narrowly, maybe based on just the title.)
When doing a factory reset because of whatever reason, this becomes an issue as well. You cannot take screenshots of the bulk export QR-Code on Android because of FLAG_SECURE, so you need to work around that and take a photo of the screen with a different device to import from later.
Also, as of last week, there existed an issue with special characters when trying to import and the app would just freeze or not recognize the QR code pattern at all, so you better had backups of all your secret keys.
Both issues made me switch to Aegis and appreciate my past self backing up the secrets with KeePassXC.
I have long migrated to Aegis and it is pretty awesome. Backups. Copy & Paste. Encryption. Auto-upload to Nextcloud. Better Interface (with names!). etc.
They maintain their own kernel module to handle ACLs (synoacl_vfs) and they are indeed enforced locally as well. They can be read and modified by using the `synoacltool` cli.
Is that kernel module open source? One of the advantages of what TrueNAS did is that I can patch it into my own kernels if I'd need to. Plus being compatible to the NFSv4 ACL binary format, so it works via NFS too. Also handling Active Directory would be important there.
Not sure about the module being open-source, but running custom kernels is not really a thing on Synology. They seem to integrate SoC BSPs into kernels for each specific model, and they do not seem to port them across versions. Different models use different kernel versions in the same DSM (Synology distro) version.
The ACLs do work via NFS and it also works with Active Directory. They ship an AD implementation too, if you are interested in that (it is actually Samba in AD mode).
Well, TrueNAS Scale isn't exactly designed to be run on a SoC, it's more of a normal linux distro for NAS/SAN Servers. Hence most of it is open source and there is active upstreaming efforts. Plus the entire ACL thing is native to ZFS already, it's just the glue layer that's missing in Linux. For Linux it's presented in an XAttr for compatibility, for Solaris it's part of the proper permission bit fields.
