Changing osmc user uid / gid

Hi all,
Is there a safe way to change osmc user uid/gid.

I have a hard time configuring NFS access with Synology NAS, which has a user uid limitation (have to be > 1024).
Google suggest that it is next to impossible to configure it properly without Kerberos / LDAP / AD which I don’t want/need,
I wonder if it is safe to just change the uid/gid in /etc/passwd? I am worried that I won’t be able to find all file other dependancies (including but maybe not limited to file ownership) and face necessary reinstall.

Have someone tried that before?
Is it doable?

@sam_nazarko Is such change “compatible” with system updates / overall system behaviour etc.?

Many thanks for the reply

P.S. Since NAS producers are making such limitations and Vero is primarily used as a player which have to have network storage, maybe it is a good idea to change the default uid of osmc user to some higher (>2000) uid…just a thought :slight_smile:

No – it will break OSMC.

But I don’t see why you need to change the UID / GID. A lot of people are using Synology NAS devices with OSMC and NFS shares.

ohh that is very bad. A lot of people may use it but probably all with squash_all option. There is almost no other way around it, to have a functional multi-user environment :frowning:

This is a problem with your NAS, not with OSMC. The osmc user in OSMC has a uid of 1000, if you read the Debian documentation you’ll find that numbering user accounts starting at 1000 is standard practice for Debian: (of which OSMC is a derivative)

https://www.debian.org/doc/debian-policy/ch-opersys.html

The same is true of many other Linux distributions, for example Redhat:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Managing-Unique_UID_and_GID_Attributes.html

On Mac OS X normal user accounts start at an even lower UID - normally 500 depending on the version of Mac OS X.

So if your NAS can’t work properly with UID’s below 1024 that is poor design on their part when UID’s less than 1024 are standard practice on most linux/unix distributions - I would contact their technical support and ask them why this is.

What’s the UID and GID of the data on the NAS that you want to access?

As it is a design decision from Synology I doubt he will have success with that remember not all manufacturers are as supportive as OSMC :wink:

https://forum.synology.com/enu/viewtopic.php?t=1205
https://forum.synology.com/enu/viewtopic.php?t=20925

You can’t change the UID of osmc but it can become a member of an additional group.

So, first create a new group using the same GID as on the Synology NAS. I’ll use 1234 in my example.

On osmc, run:

sudo groupadd -g 1234 synology

then add osmc to the synology group:

sudo usermod -a -G synology osmc

Then logoff and logon again. Type groups (or id) to check if you’re in the synology group. You then need to set whatever permissions you want for the group’s access.

Thank you for all tips. I am afraid that I’ve tried more or less all aproaches without any luck to make it properly functioning multi-user environment. At least not the way I was used to using Linux based NFS server on Debian.

We are hardly in position to question Synology’s decisions here as their product is in top 3 (if not top 1) of small business / home NAS solutions.

Also QNAP users are strugling with uid mapping scenarios, so I suspect that their devices may have similar limitations.

I am not saying that osmc have bad design (and I understand that as debian based distro it uses similar logic). I was just wondering if it can be changed (the uid I mean). Normally on Debian or Ubuntu changing the uid is doable. It only requires changing the file ownerships.

That is why, I hoped that I can accomplish similar change on OSMC.

I am just curious, why it cannot be done. Does someone know that? If this is a matter of running some chown commands after updates, I can live with that.

@sam_nazarko can you give me a hint? I doubt that it will break everything. If you confirm it will beyond the possibility to somehow make it work even in semi-automatic way, I’ll accept it and I’ll try to look for some different workarounds.

TIA

The use of the GID is a tried and tested method. I’ve done it many times and it normally works.

Could you show me the permissions of the files on the NAS and what you’ve done on the OSMC side?

I am sorry but i messed up the permissions now so much, trying lots of different ways to make it work, that I cannot show anything to anyone right now :slight_smile:. I have to reset all settings and start from scratch.

I acknowledge the group workaround possibility. Thanks for that tip. I haven’t consider it before, because I tried to make it work using one dedicated UID (for each purpose) across all relevant devices / OSes, like I have now (I am currently trying to migrate all my data to Synology).

After failing miserably with UID mappings on NFS level, I came up with the changin UID across all devices idea.

That is unfortunately also not possible so I’ll go back to other workarounds like this GID idea and probably end up making dozen of small shares (instead one big multi-user one) and use squash_all option for some of them like osmc to access the “Video” share as synology admin user, exactly how it is describe on Kodi wiki for newer versions of Synology devices.

Just for you to understand the concept:
Right now I have one NFS share which is exported to more or less everything, with only the root_squash option. So no matter what device I am using if I have my uid I can access my files and not someone elses. Such simple solution and yet now it turned out to be next to impossible to replicate on “professional” and not to mentioned expensive device, but it was pretty easy to configure on homemade nas server based on CuBoxi and esATA disk.

It’s not a workaround. It’s standard procedure.

If you look around, I’m sure you’ll find a lot of examples of how to use GIDs on NFS.

Read-only stuff is very straightforward. Read-write can be more of an issue but is doable.

Yes on normal NFS on ext it’s correct. Here, though, I have btrfs with no possibility to use standard acls (via setfacl)

In such mixed environment: Linux rights / BTRFS rights / Synology rights not to mentioned also CIFS shares of the same directories its really extremly hard to make this all work.

As I wrote before though - I haven’t tried the GID mapping with all possible scenarios. I am going to try those with other workarounds and hopefully after another week I will finish migration to new NAS. :slight_smile:

I am going to mark your answer as a solution because it is the closest thing to a solution that it seems it can be. Thanks again for the hint.

Just a follow up. Maybe someone will find it helpfull
I tried the group approach but it is not working. The only way on Synology to make this work is to use synoacltool, but then every chmod breaks the permission structure and you have to manually correct it from synology shell - not very good.

At the end this is what I did:

  1. I created some users on Synology (eg. 2000,2001,2002, etc. where 2000 is main user for managing Video files)
  2. I changed the user UIDs on all systems / devices except osmc to match exactly those on Synology
  3. I made all necessary find / -uid XXX -exec chown XXX {} ; stuff on all systems
  4. I changed owner group of the share folder under /volume1 to correct user and group and then chmod 775 just to access the root folder
  5. I exported the share from Synology with only root_squash option for all devices except OSMC
  6. I exported the share from Synology with all_squash option and anonuid = 2000 for OSMC
  7. I exported the share via CIFS so that the windows computer can authenticate using the 2000 user to access / modify all video files or any other user to access their respective files.

That way I can:

  • stick to only linux permissions without the problematic synoacltool and extended ACLs conflicts
  • OSMC have full RW permissions on the whole share pretending to be the “main video” user with uid 2000
  • All other users on all other devices have the permission structure unchanged and respectable UID/GID information are keeping the environment more or less secure.
  • occasional CIFS mounts also are manageble (with the exception that umask is 000, but as I said this is occasional usage only and I can force the other permissions from linux afterwards, but I can at least see and manage the files created via cifs.