Sambashare fixes

Development
1

@kc2bez

  1. Hey could you update the bug with any information about the Calamares version number and/or commit that fixes this?
  2. Do we have a task for this with details on what we need to modify in the config?
  3. Is this something we can possibly backport? What would be the implications for users that already have their system set up? Alternately, we should create instructions to resolve the issue.

(see link for context)

2 Likes
2
  1. I think I updated the bug properly.
  2. I made a task
  3. I don’t know about backporting since we need a big jump in cala versions. We wouldn’t be able to respin isos but maybe we could get it in a point release?
    I am unsure how to cleanly fix this for currently installed systems.
    I think this would only impact files and permissions if mounting them from a previous system. Any newly created files will have the updated UID/GID. Any fix applied will need to account for that.
3 Likes
3

Fair point. We can probably skip that, as unfortunate as it is.

This is something we will need to investigate for people like the OP. I have seen it mentioned before, though I couldn’t quite unravel what the deal was, so I’m glad you figured out.

From what I can tell, when a user’s GID is changed, the UID will be updated for files in the user’s $HOME but the GID will not be changed anywhere. The following would be the appropriate fix, I think:

Prerequisites

  • any supported installation of Lubuntu > 18.04
    • this should include a sambashare group with GID 1000
    • this should also include an initial user with UID 1000 but GID 1001

Solution

  1. change the sambashare group to a GID < 1000 (i.e. a system group)
  2. change the initial user’s GID to 1000
  3. fix the files
    # change group for all files with bad GID
sudo find / -group GID -exec chgrp -h USERNAME {} \; 

# change ownership on files outside $HOME
sudo find / -user UID -exec chown -h USERNAME {} \;
    where:
    • USERNAME is the user’s username. In the event of the logged in user, that’s $USER
    • GID is the old (or incorrect) GID for the user (for a single user, 1001)
    • UID is the UID for the user (for a single user, 1000)

This process would need to repeated for additional users, as each additional user with its own group would mean an increment to the UID (unless otherwise specified) and an increment to the GID (unless the main group was reused, which would be rather bizarre).

3 Likes
5

A quick test can be found on the following link

https://notes.lubuntu.me/kYZJs5a3SimFpmP-Y2ZcVw

My purpose was primarily testing of @wxl’s

sudo find / -group 1001 -exec chgrp -h $USER {} \;
sudo find / -user 1000 -exec chown -h $USER {} \;

I had read Walter’s post yesterday & didn’t re-read it today (first), so my order was mucked up…

I ran the commands before I changed the GID to 1000, so a number of files were on logout still showing 1001 as GID; (I had featherpad open for my notes, qterminal for commands, plus firefox to read this post; end-users will likely have firefox [instructions they are following] & qterminal open too

I logged out, then changed /etc/passwd so GID was 1000, and on login again, everything appeared to work normally, created (touch) files all had 1000/1000 I didn’t have any issues with the mainly .cache files which where GID=1001 (owner was still me)

I wasn’t sure why sudo find / -user 1000... was needed, but did it too.

The main issue is how to document, and get users to perform it (those that need to, esp. changing $GID which wasn’t mentioned in Walter’s post).

Even with my failing to follow instructions (missing the per-requisite), as an end-user I’d consider it a success.

It’ll mean we have users at the 20.04->22.04.1 upgrade path with varying group settings of course…; but users are always changing things… so that’s not new. I’ll continue playing and looking for flaws.

Later edit: I’ll add, should a user have used my order, running the

sudo find / -group 1001 -exec chgrp -h $USER {} \;

a second time, on next login (after GID had changed) would have corrected the missed files (which weren’t actually missed; they just got re-changed by my in-use user account writing to them using the then-correct older GID settings).

3 Likes
6

Hah! Well, that’s good to know! :laughing: The backwards ordering in my post is why I said it needs better organization. I’ll get on that ASAP and we’ll just refer to that going forward as needed for anyone that needs it. So let’s keep it in our thinking caps :slight_smile:

2 Likes