After upgrade to KDE 4.10 which now uses udisks2 in Gentoo I'm not able to mount any of flash drives.
Short investigation shows that problem lays in udisks2 hard dependency over ACL support. While it is absolutely OK to use it when it present, it would be nice to have some kind of fallback for systems (or filesystems) where ACLs are not supported at all.
It seems that this could be easily fixed by attached patch.
Steps to Reproduce:
1. Install udisks2
2. Insert flash driver / CD/DVD
3. Try: udisksctl -b /dev/sr0 mount
Adding read ACL for uid 1000 to `/run/media/ostash' failed: Operation not supported
Get media mounted
Created attachment 339550 [details, diff]
Fallback to /media if ACL is not supported
According to a forum post, all that's needed to fix such problem is CONFIG_TMPFS_POSIX_ACL=y.
Why I need to rebuild kernel if userspace tool doesn't behave correctly?
Anyway, it could happen that in setup /run isn't on tmpfs.
1. this is an explicit choice made by usptream and after quite a few discussions
2. the ebuild explicitly checks and warns about it (in two different cases)
CONFIG_CHECK+=" ~TMPFS_POSIX_ACL" bug #412377
There is imho nothing to "fix" here as this will be a patch to carry forever and I do not think ACL is a crazy requirement (like kerberos would be for example) for modern desktop (even with a single user).
(In reply to comment #4)
> 1. this is an explicit choice made by usptream and after quite a few
> 2. the ebuild explicitly checks and warns about it (in two different cases)
> CONFIG_CHECK+=" ~TMPFS_POSIX_ACL" bug #412377
> There is imho nothing to "fix" here as this will be a patch to carry forever
> and I do not think ACL is a crazy requirement (like kerberos would be for
> example) for modern desktop (even with a single user).
I agree, and I doubt upstream will take the patch:
So we shouldn't be carrying it either. And since the ebuild has the kernel option check, the package is actually already OK in portage.
If upstream takes the patch and plans on supporting non-ACL kernels, please reopen this bug!
*** Bug 462492 has been marked as a duplicate of this bug. ***