Understanding file permissions

mt_arch_user · 2025-08-20 21:33:22

I have 4 computers and a file server on my network. 3 of the computers are running Arch, the other computer and the server are using openSUSE. The computers are using KDE, the server is headless and has no graphical interface.

The server is mounted on each computer using fstab.

DEL-OSS:/home/common   /mnt/DELL-Server  nfs   rw,nofail,user  0  0

On each computer, in the home directory, is a link pointing to /mnt/DELL=Server, to access it.

I'm having trouble accessing files created on one computer being accessed on another. I mean if I create a file on my computer using my account, copy that file to the server and then try to access it from another computer using my account on that server, I'm denied access. That seems to be proper as my user account and group account numbers are different on the different machines.

My understanding is that the access is controlled by the number assigned to a user and group and not by the name. Looking at /etc/group on each computer confirms each one has different numbers for users and groups with the same names.

Changing the permissions to 777 on the file or directory allows access, however that doesn't seem to be a good idea.

My first thought is to change the user and group numbers on each computer so that they would all be the same on all systems. But then I'd probably lose access to existing files!

If I did do that, is there a way to change the user numbers and group numbers, on all existing files, recursively, on each machine? Would that be a really bad idea? Or am I missing something that should be obvious?

ewaller · 2025-08-21 01:20:16

The thing that matters is the numeric UID, not the user name. I bet the UID numbers are different for for the same user name on the different systems. Compare the output of ls -l versus ls -ln on the various machines.

seth · 2025-08-21 07:05:49

mt_arch_user wrote:

Looking at /etc/group on each computer confirms each one has different numbers for users and groups with the same names.

You're winning that bet

https://wiki.archlinux.org/title/NFS#NFSv4_idmapping but that doesn't work w/ nfs3

If you want to change the UID/GID of all files on a system you'll probably have to leverage find, https://www.cyberciti.biz/faq/linux-cha … ned-files/ (nb. that the "find … -exec chown…" stuff there is run as root, your regular user cannot re-own files)

777 is probably not the best answer, https://man.archlinux.org/man/chmod.1 - see the uppercase "X" behavior and then you could probably still utilize special groups (ie. have users of all systems be part of a dedicated "$USER_nfs" group w/ a GID common on all systems.
Then there's https://aur.archlinux.org/packages/bindfs/ which allows uid mapping bind mounts

mt_arch_user · 2025-08-21 08:38:30

Unless someone comes up with a better system, my plan is to change the user numbers and group numbers so they match on all machines. If I create a new user or group, I'll have to specify the numbers for them. But, before I do that I'll need to go through every file, on every machine and change the user and group ownership of every file there. Of course, at that point there will be no access to anything until I change the user and group numbers. I;m thinking I'll even have to do root . That scares me!

I've already started on a script to do the file owner and group numbers. I've not done much bash scripting. Man, oh man am I slow with it! Seems like every line requires a search for the command and another instance of Konsole to view the man page! I'll most likely be back with some really newbie questions.

When, not if, I get this down, should I post the scripts and procedures I did for reference?
Bart

seth · 2025-08-21 12:04:42

Did you see https://www.cyberciti.biz/faq/linux-cha … ned-files/
And yes, you will have to run that as root.
Create some test directory in /tmp w/ some test files and run the process there first before starting to shred your data

mt_arch_user · 2025-08-21 20:25:35

seth wrote:

Did you see https://www.cyberciti.biz/faq/linux-cha … ned-files/
And yes, you will have to run that as root.
Create some test directory in /tmp w/ some test files and run the process there first before starting to shred your data

Thanks for that link! Has some info that will help. My script is creating a log file and I intend to accept a parameter to make it do a test run showing what will be done before doing it. Should eliminate some of the shredding.

Arch Linux

#1 2025-08-20 21:33:22

Understanding file permissions

#2 2025-08-21 01:20:16

Re: Understanding file permissions

#3 2025-08-21 07:05:49

Re: Understanding file permissions

#4 2025-08-21 08:38:30

Re: Understanding file permissions

#5 2025-08-21 12:04:42

Re: Understanding file permissions

#6 2025-08-21 20:25:35

Re: Understanding file permissions

Board footer