Udisk2 assigning UID/GID of 1023 to anything mounted by user
 

I'm having issues trying to figure this one out:

I can mount USB flash media from within Thunar or Dolphin from my regular user just fine. However when I try to eject/unmount it fails with operation not permitted. When looking at the mount point it somehow has the ownership of 1023:1023 (so, not an actual user or group on this system). I can't find any worthwhile occurance of '1023' anywhere in /etc. Then only thing I changed from my slackware64 14.2 install from the configuration side was I added a udev rule to mount all media in /media instead of /run/media/[username] with this udev rule:
I've added my user to the 'disks' and 'plugdev' groups and have tried adding to the above rule without any luck.

Any ideas?

When I look in my /media directory, there's a bunch of other stuff already in there (dating from 2006, 2012, and 2016). Why did you want to move your automounts to /media?

What's the result of running?

people don't like new things

the idea of mounting a filesystem which may never been seen more than once to a mountpoint on a tmpfs which will not persist scares people.

regards the UID/GID being 1023

Where are you getting those from ?

are you looking at the UID/GID of the files on the filesystem?

@brendan_orr

I'd suggest to focus only on udisk and try rebuilding it with "--enable-fhs-media", as suggested here:
https://askubuntu.com/questions/1140...-of-media?rq=1
& here:
https://www.linuxquestions.org/quest...ml#post5966545

Patching it could be also interesting depending on your use case:
https://www.linuxquestions.org/quest...ml#post5516038

If you want to stay with udev, you could employ some scripting with it:
https://unix.stackexchange.com/quest...-inserted-with
And, on your udev rule, if you still want to keep it, consider the last recommendation from this article related to "clean stale mountpoints at every boot":
https://wiki.archlinux.org/index.php...media_(udisks2)

Extra, a short summary about the history&rationale on moving the mounts from /media to /run/media
https://unix.stackexchange.com/quest...-and-run-mount

It looks like 1023 is the UID and GID of Android user and group "media_rw".

Is it possible that your flash media has been formatted and/or recently used on an Android platform?

That does seem to fit nicely.

I think the OP just needs to undo the unnecessary changes they made.

the userbase of slackware does seem to be in need of basic education

Actually, rather than any irrational aversion to "new", I think it's more to do with the fact that /media/mountpoint is shorter than dealing with /run/mount/$user/mountpoint and contains no variable parts. GUI point and clickers might not care where things get mounted, command-line jockeys more so. Obviously there are cleverer ways of handling this than changing the directory where mounting occurs back to the old location, but I understand why some might choose to do so.

And you need to learn some manners. Welcome to 'ignore'.

as someone who favours the command-line I see no difficulty in /run/media/${USER}/Label

I am reminded of the various swine (who, IIRC, all used Debian) that invaded the old Slackware USENET group years ago for some reason.

I think everyone can see exactly who is in need of basic education.

Debian, the distro that maintains the 'posh' shell which is used to test against debian policy and yet contains a massive memory leak that can trivially take down any system it has been built on.

Which is yet another issue debian ignores.

https://bugs.debian.org/cgi-bin/bugr...cgi?bug=911432

I ignore it
here is a good one for you

root partition 12GB
slackware 14.2
works fine ;)

now, set your mirror to current and do upgrade-all

sit back and watch the install scripts fail over, and over , and over ... over again.

poor quality scripts

What do you expect install scripts to do when you don't give them enough space? That is clearly user error. Slackware does that great, it does exactly what you tell it to do. If someone wants to break their system by removing glibc it lets them without complaint. Debian on the other hand is notorious for trying to remove the entire system when removing a package like *xchat.

Whether you use posh or not, I am personally wary of developers who ignore critical issues.

I wouldn't have suspected Android, as I didn't know that (useful) bit of information aobut the uid/gid it uses there; however, I *do* suspect that you are spot on with respect to the issue.

If there's a unix-type filesystem on a removable drive, then a unix-type OS is going to respect the ownership and permissions on that filesystem. To the OP: if that's not what you want, then you need to put something like vfat, ntfs, or exfat on there.