Two distros sharing data on separate HD

I want to keep my data on a separate data-only hard drive and be able to mount it on more that one distro, one not being Suse. I am concerned that access to a second distro will create problems when I back up the data drive. That access might change permissions or ownership and cause every backup to start all over again. Could someone with a similar setup please advise me? Thanks in advance.

I do not understand your concerns. When a file system is used (mounted on a directory) by a system, of course things may change there. Not “spontaneous”, but by the actions done on the system by e.g. the users. They add files, remove files, change files, change permissions, maybe even change owners of files, etc. I do not think that is a surprise to you, after all that is why you mount that file system on different systems, to make it available for actions on those different systems.

As you do not even mefntion on what base “backups” are made and how, I can not add much about that. I have no idea if you make backups of files o the multi-mounted file system on only one system, or on more systems. And to where you make those backup(s). What criteria. What tool (based on what). Too many uncertainties here. It is if you think that everybody has the same backup policy and implements that with the same method. I ca assure you that that is not the case.

Permissions of text files created in Leap show the owner as being myself and the group being “users”. Text files created in a different O.S. show the same owner (as I am the only user) but with a group named “1000”. I use

rsync -av --delete

to backup my files and wonder if this might affect backups from the shared drive to yet another drive.

UNIX is using numerical UID and GID as user identity. Those numbers are local to each operating system instance, It has been this way since the beginning, for the past 50 years. Are you trying to tell us that you never heard of it?

If you want to share data between multiple UNIX operating systems, you are responsible for making sure the same users and groups (whatever “the same” means to you) have the same UID and GID on every system that has access to shared data. Or you use filesystems that do not store UID/GID at all and their drivers emulate them and allow you to fake any UID or GID with each mount.

As $avidjaar says.

Then on the one system the GID 1000 is named users and on the other systems it is not found in /etc/group and thus the tool you use to show falls back to the numeric GID.

It backs up with the UID and GID as attached to the files (in their inodes). Not with their username and groupname. Username and groupname are only easy to understand for human beings, but they are not the crucial information.

While what @avidjaar says is clear enough (I hope). I want to stress that from a security point of view it is very imprtant that on systems that work close together in using file systems (if that is through mounting eacch at different times, or at the same time through e.g. NFS) use the same user and group names for the same UID and GID on all systems.

It is even so that it is more important that you, as a person, have the same UID on both systmes and less important that you have the same name iomich on same systems.
Think it over. When ionmich has UID 1000 on system A, but henk has user 1000 on system B, then henk would have the same rights on those files when he uses them from system B as ionmich would have when he uses them from system A. Thus I could, from system B read, alter, destroy, whatever.

Thanks to both of you. I understand the dangers now.

Well, I do have such a setup since years now. All users are me regardless of the uid. They have a distinct group id and additionally group 100 (=users). If I create a guest account, it does not belong to the group users.

The common data filesystem has now the SGID bit set (=Set Group Id).

 # chmod g+s <directory>

Thus any directory and file inherits the group users. Another approach would be the use of ACL (Access Control Lists), but it looked much too complicated at that time.

Best regards,
Bequimão