Why directories symlinked from a separate partition marked as owned by a non-existent user?

Hi,

I have noticed an issue that is very irritating about Tumbleweed. All folders (and I think files too) symlinked from my data partition (automounted on start up as it’s mentioned in my fstab file) are owned by a non-existent user named ‘linux’. This is irritating as these messed up permissions are …ing up my other distributions and their behaviours based on these folders. My fstab file is:


UUID=d4c22fbc-9b71-4387-9c91-2738363aff35 swap swap defaults 0 0
UUID=e03686b3-9112-4435-b0bc-9dcf749008ba / btrfs defaults 0 0
UUID=e03686b3-9112-4435-b0bc-9dcf749008ba /boot/grub2/i386-pc btrfs subvol=@/boot/grub2/i386-pc 0 0
UUID=e03686b3-9112-4435-b0bc-9dcf749008ba /boot/grub2/x86_64-efi btrfs subvol=@/boot/grub2/x86_64-efi 0 0
UUID=e03686b3-9112-4435-b0bc-9dcf749008ba /home btrfs subvol=@/home 0 0
UUID=e03686b3-9112-4435-b0bc-9dcf749008ba /opt btrfs subvol=@/opt 0 0
UUID=e03686b3-9112-4435-b0bc-9dcf749008ba /srv btrfs subvol=@/srv 0 0
UUID=e03686b3-9112-4435-b0bc-9dcf749008ba /tmp btrfs subvol=@/tmp 0 0
UUID=e03686b3-9112-4435-b0bc-9dcf749008ba /usr/local btrfs subvol=@/usr/local 0 0
UUID=e03686b3-9112-4435-b0bc-9dcf749008ba /var/cache btrfs subvol=@/var/cache 0 0
UUID=e03686b3-9112-4435-b0bc-9dcf749008ba /var/crash btrfs subvol=@/var/crash 0 0
UUID=e03686b3-9112-4435-b0bc-9dcf749008ba /var/lib/libvirt/images btrfs subvol=@/var/lib/libvirt/images 0 0
UUID=e03686b3-9112-4435-b0bc-9dcf749008ba /var/lib/machines btrfs subvol=@/var/lib/machines 0 0
UUID=e03686b3-9112-4435-b0bc-9dcf749008ba /var/lib/mailman btrfs subvol=@/var/lib/mailman 0 0
UUID=e03686b3-9112-4435-b0bc-9dcf749008ba /var/lib/mariadb btrfs subvol=@/var/lib/mariadb 0 0
UUID=e03686b3-9112-4435-b0bc-9dcf749008ba /var/lib/mysql btrfs subvol=@/var/lib/mysql 0 0
UUID=e03686b3-9112-4435-b0bc-9dcf749008ba /var/lib/named btrfs subvol=@/var/lib/named 0 0
UUID=e03686b3-9112-4435-b0bc-9dcf749008ba /var/lib/pgsql btrfs subvol=@/var/lib/pgsql 0 0
UUID=e03686b3-9112-4435-b0bc-9dcf749008ba /var/log btrfs subvol=@/var/log 0 0
UUID=e03686b3-9112-4435-b0bc-9dcf749008ba /var/opt btrfs subvol=@/var/opt 0 0
UUID=e03686b3-9112-4435-b0bc-9dcf749008ba /var/spool btrfs subvol=@/var/spool 0 0
UUID=e03686b3-9112-4435-b0bc-9dcf749008ba /var/tmp btrfs subvol=@/var/tmp 0 0
UUID=e03686b3-9112-4435-b0bc-9dcf749008ba /.snapshots btrfs subvol=@/.snapshots 0 0
UUID=D796-7F56       /boot/efi            vfat       umask=0002,utf8=true  0 0
/dev/sdb1                   /data                ext4       defaults              0 1
/dev/sda6                  /fedora              btrfs      defaults              0 1

Funny thing is that I automount my data partition this way on other distributions (including Arch, deepin, Fedora, Gentoo, KDE Neon, Linux Mint, Mageia and Void Linux) and on these other distributions this problem has never happened. Is this like an AppArmor feature or something?

Thanks for your time,
Brenton

Long fstab, but which entry are you talking about?

Is that the one with mountpoint /data? (I assume you may have used this mount point for what you use loosely “my data partition”.

All folders (and I think files too) symlinked from my data partition

One often creates symlinks from e.g. a place inside ones home directory to a directory/file in a partition outside one’s home directory. It is not clear to me from the above if you mean this, or if you mean that there are symlinks from inside /data to other places (that is what is read in your statement. So please explain again what is symlinked to what. As always illustrating your statemenst/conclusions with computer facts like, in this case, ls -l listings from at least one example says much more then thousand words.

In any case, please provide computer information about ownership of file on /data, both with user names group names and with uids, gids:

ls -l /data
ls -n /data

Never mind I think the problem was that I had a user that was automatically created from the Tumbleweed installer (not sure why) that was called “Live CD user”. The permissions were set like the Live CD user was going to use these files. I think this user was called ‘linux’, I didn’t realize a user named linux existed, but just encase I ran userdel linux and now the Live CD user doesn’t appear in the user accounts section of GNOME settings and the folders do not seem to be changed in ownership so that this user was the owner instead of my user (I use the same user across all distros so that permissions issues on the /data partition should not arise. The permissions were set so my user owned all the files on this partition). So therefore I assume that this “Live CD user” was the ‘linux’ account and due to this account’s presence my /data partition’s files permissions were being changed so that this user could read and write data from/to it.

Hi fusion809!

You should be careful when using the same partition over various distros.
I’ve been bitten a few times, because not all distros use the same convention when assigning user IDs.

Let me explain: on openSUSE I see that UIDs for system users are all < 1000, while UIDs for local users are >= 1000.
Another distro could be using a different convention, so that user 1000 (that typically on openSUSE is your local user) could be mapped to a system user.
Ownership, at the file system level, is recorded using UIDs and GIDs, not using the name of the user and group, so when changing distro you may find that your files are mapped to a completely different user/group.

The solution is to directly assign the UID to your user name when installing a new distro (typically installers let you do this, but the setting is hidden behind an “advanced settings” button or something like this).

Hope this helps…
Cris

Thanks it does help as unfortunately this issue has persisted. Is there a way to fix this post-install?

It seems like ol’ Tumbleweed uses the UID of 1001 for my user while my other installed distributions (of which there are ~10) uses a UID of 1000. To correct this I signed out of my user account and ran:


usermod -u 1000 fusion809

as root.