How to disable the local group file (forever)?
This is not a Good Idea(tm). Attempts to do this would be very "impactful"
Or is there any other workaround?
You mention the following, which sounds like this occurs whenever the servers are patched and rebooted.
"...whenever a package is updated that has something to do with groups..."
One "least impactful" solution would be to create a custom init script to remove the staff
group from /etc/group
when the system changed run-levels (exactly which ones depends on what's in the procedure you use to patch the servers)
See the Debian documentation on their init-scripts for details.
The short of it is that NFSv4 protocol relies a username being shared between the server and client, and not the UID/GID numbers (which were used in the earlier versions) and the UID <==> username mapping can actually be different on the client and the server.
As part of the NFSv4 protocol both the server need to map the common security contexts/permissions, owner and owner_group to something that makes sense for the local file-system operations. That mapping is done by IDMAPD on Linux systems.
On a Linux system many local file-systems operations are UID/GID based but those need to be translated to the shared NFSv4 context before they can be transmitted to the NFS server.
Maybe RFC 3530 can explain it better:
ยง 5.8. Interpreting owner and owner_group
The recommended attributes "owner"
and "owner_group"
(and also
users and groups within the "acl" attribute) are represented in
terms of a UTF-8 string. To avoid a representation that is tied to
a particular underlying implementation at the client or server, the
use of the UTF-8 string has been chosen. Note that section 6.1 of
[RFC2624] provides additional rationale. It is expected that the
client and server will have their own local representation of owner
and owner_group that is used for local storage or presentation to
the end user. Therefore, it is expected that when these attributes
are transferred between the client and server that the local
representation is translated to a syntax of the form
"user@dns_domain"
. This will allow for a client and server that do
not use the same local representation the ability to translate to a
common syntax that can be interpreted by both.
Edit in response to your imapd.conf.
You using a static mapping to local user. You probably want to map the NFSv4 identities to LDAP users, which probably should should happen by the nsswitch
option, but apparently is not. You could try to see what is happening by increasing the verbosity of the idmapd on the NFS server.
Alternatively configure idmapd to directly query your LDAP server. The exact syntax may depend on the version you're using, but the man page shows something along the lines of :
[General]
Verbosity = 0
Domain = domain.org
Local-Realms = DOMAIN.ORG,MY.DOMAIN.ORG,YOUR.DOMAIN.ORG
[Mapping]
Nobody-User = nfsnobody
Nobody-Group = nfsnobody
[Translation]
Method = umich_ldap,nsswitch
GSS-Methods = umich_ldap,static
[Static]
johndoe@OTHER.DOMAIN.ORG = johnny
[UMICH_SCHEMA]
LDAP_server = ldap.domain.org
LDAP_base = dc=org,dc=domain
Best Answer
you have to make sure you are using the LDAP user. Check with
id
if u are actually the LDAP user and not a local user when writing the file.By the way you write im taking you are trying to write from a different server. If so does this machine also use the LDAP or are you using a local account? because this user will use its own uid when writing the file.
things you can check:
/etc/nsswitch.conf
for the order in which a machine uses files or ldap for retrieving account informationgetent passwd
to check if it even know the ldap user