Pardon the long explanation. I use Ubuntu 20.04. I am the only person that uses this system. It's my "daily-driver". So it and it's content is very important. There are 4 users of concern, bruce, chad, jack, fred. 5 years ago, Gnome/MATE was used by all. All users are currently set up as (owner, group identical) as in "bruce+bruce", "chad+chad" and so on.

I use a music composition/notation software called MuseScore. It is cross-platform (Linux, macOS, Windows). I need it to function optimally, all the time. Version 3.6.2 (latest) of MS was installed in fred, under '/home/fred'.

Dec '22 I modified fred's desktop to the latest KDE/Plasma release. By late Jan '23, I started noticing MS was getting sluggish when program menus were selected, opening pop-up windows. In the last few weeks, to open certain pop-up windows can take around 1min 40sec to paint and become available. Normally this would happen in a few seconds at most.

I've reached out to MS's community & tech support, but no suggestions for remedy have come. I believe that as updates happen to the KDE/Plasma desktop, elements of that architecture are producing this problem w/ sluggish program response in some cases.

I back up my MS music scores to a separate partition called '/oflow' for redundancy. There happens to be a partition called '/extra' that contains much data. /oflow & /extra are completely arranged under "bruce+bruce". The first graphic illustrates the current situation. And shows I am hoping to MOVE the MuseScore environment from fred to jack -- an XFCE4 desktop.

Along the way, I tested the Budgie desktop on user chad, but was not impressed by its look & feel. I have tested 3 release versions of MS (3.6.2, 3.7.x development, 4.0.1) on jack's XFCE4 desktop, and it works fine & snappy.

What I am hoping for is to create a 'unifying' access mechanism by assigning all users & their desktops to use new group 'everybody'. This way, if I'm logged-in to jack (/home/jack) I should be able to more easily access other user's data without repeated 'sudo' actions. The second graphic shows what I hope will work.

I've never found need to assign multiple login-id's to the same group. Now I think it will mean a way to make this scenario work.

Comment? Suggestion? Appreciated.

Attached Thumbnails

   

I wouldn't change everybody's PRIMARY group to a shared one.

Just create a 2ndary group for muse called eg muse and add that to everyone who needs it https://www.howtogeek.com/50787/add-...roup-on-linux/.
Ensure all relevant muse files/dirs have that group.

In fact normally for this sort of situation, you'd create user+group muse:muse and install muse as that user, then use the above link to add 'muse' as the 2ndary group to the relevant users.

Yes, that will work. That is what groups are for. In additon to user:group ownerships, you will also want to check the permissions, and set them how you like: do you want to just be able to read the other users data, or to both read and write over? Do the other users data contain executeable files, and do you want to be able to execute them. All of these variances are achieved with the change mode command (chmod). You can set the group with the change ownerhsip command (chown). Of course you first have to have created the group, which you can do with the command to add a group (groupadd).

But as Chris points out... that's a lot of trust amongst users, so you can just use the shared group on their music score data folders instead of their entire home folders.

You could also create a dedicated music score directory that's not in anyone's home directory to share amongst the group, and all the users can put their data in it.

Yes, I didn't make the latter explicit; create a shared dir for music files that need to be shared.
Installing a service under its own user+group often does that anyway...

Never get into the habit of sharing users' home dirs / files directly.

It's sufficient if they are all members of the shared group and that the group has read-write access to the directory. If they are to share write access to individual files, then you'll need to work with the SetGID bit and maybe umask, at least with EXT4.

I appreciate the comments that have come from my OP. I'll have to investigate the points raised, including the "umask & SETgid" things. Also, I am now studying the ACL (access control list) functions in Linux.

The various male names all are myself, just there to segregate desktop environments...