[SOLVED] Can't write on an NFS4 volume although permissions look good

elgmizik · 2025-10-30 12:43:28

I have mounted an NFS share by following the arch wiki's instruction

The server is a raspberrypi4 running yunohost (raspi OS with some hosting / admin high-level tools). My client is a desktop PC running arch, kernel 6.17.5-arch1-1

Configuring id mapping seems to work fine: my user doesn't have the same uid/gid on both machine, yet my username shows on the client. I'm mounting the volume using a system unit, as explained in this section of the wiki.

I can access to all files, when I `ls -l` on the client side, I see:
- this for directories:

drwxr-xr-x   3 myuser myuser 4.0K

- this for files:

-rw-r--r-- 1 myuser myuser 9.3M

which looks good to me. But I cannot `touch` any file inside this directory: I get a `permission denied` error.

The output of `mount` on the client shows this:

192.168.1.16:/music on /mnt/music type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fatal_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.11,local_lock=none,addr=192.168.1.16)

which also seems to look good, with `rw` permissions.

I don't know what to look for next

Thanks for your help

Last edited by elgmizik (2025-11-16 16:20:31)

seth · 2025-10-30 19:29:02

Is the nfs server running as root user?
Have you checked its logs?

elgmizik · 2025-10-31 10:57:29

Hi,

The nfs-server is running through the systemctl service shipped with the nfs-kernel-server package on the raspberrypi, so if I understant correctly it is run by root yes.

Here is the ouptut of `systemctl status nfs-server`

● nfs-server.service - NFS server and services
     Loaded: loaded (/lib/systemd/system/nfs-server.service; enabled; preset: enabled)
    Drop-In: /run/systemd/generator/nfs-server.service.d
             └─order-with-mounts.conf
     Active: active (exited) since Thu 2025-10-30 10:36:21 GMT; 24h ago
   Main PID: 3160 (code=exited, status=0/SUCCESS)
        CPU: 10ms

The output of `journalctl -xe -u nfs-server`

Oct 30 10:36:21 myserver.noho.st systemd[1]: Starting nfs-server.service - NFS server and services...
░░ Subject: A start job for unit nfs-server.service has begun execution
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░ 
░░ A start job for unit nfs-server.service has begun execution.
░░ 
░░ The job identifier is 1363.
Oct 30 10:36:21 myserver.noho.st systemd[1]: Finished nfs-server.service - NFS server and services.
░░ Subject: A start job for unit nfs-server.service has finished successfully
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░ 
░░ A start job for unit nfs-server.service has finished successfully.
░░ 
░░ The job identifier is 1363.

The output of `journalctl -xe -u nfs-idmapd`

Oct 30 10:44:57 myserver.noho.st systemd[1]: Starting nfs-idmapd.service - NFSv4 ID-name mapping service...
░░ Subject: A start job for unit nfs-idmapd.service has begun execution
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░ 
░░ A start job for unit nfs-idmapd.service has begun execution.
░░ 
░░ The job identifier is 1478.
Oct 30 10:44:57 myserver.noho.st rpc.idmapd[3310]: Setting log level to 0
Oct 30 10:44:57 myserver.noho.st systemd[1]: Started nfs-idmapd.service - NFSv4 ID-name mapping service.
░░ Subject: A start job for unit nfs-idmapd.service has finished successfully
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░ 
░░ A start job for unit nfs-idmapd.service has finished successfully.
░░ 
░░ The job identifier is 1478.

What is a little surprising is the `Setting log level to 0` in this last journal, since I tried to set a high verbosity in `/etc/idmpad.conf`

Last edited by elgmizik (2025-11-03 16:43:14)

seth · 2025-10-31 13:16:23

ps aux | grep nfs # on the server

little surprising is the `Setting log level to 0` in this last journal, since I tried to set a high verbosity in `/etc/idmpad.conf`

systemctl show nfs-idmapd

Please don't use -x w/ journalctl, it just spams the output.

elgmizik · 2025-10-31 13:21:42

nfs processes:

root          66  0.0  0.0      0     0 ?        I<   Oct30   0:00 [kworker/R-nfsiod]
root         701  0.0  0.0   4928  2648 ?        Ss   Oct30   0:00 /usr/sbin/nfsdcld
root        3162  0.0  0.0      0     0 ?        I    Oct30   0:02 [nfsd]
root        3163  0.0  0.0      0     0 ?        I    Oct30   0:00 [nfsd]
root        3164  0.0  0.0      0     0 ?        I    Oct30   0:00 [nfsd]
root        3165  0.0  0.0      0     0 ?        I    Oct30   0:03 [nfsd]
root        3166  0.0  0.0      0     0 ?        I    Oct30   0:01 [nfsd]
root        3167  0.0  0.0      0     0 ?        I    Oct30   0:00 [nfsd]
root        3168  0.0  0.0      0     0 ?        I    Oct30   0:00 [nfsd]
root        3169  0.0  0.0      0     0 ?        I    Oct30   0:01 [nfsd]

nfs-idmapd service:

Type=forking
ExitType=main
Restart=no
NotifyAccess=none
RestartUSec=100ms
TimeoutStartUSec=1min 30s
TimeoutStopUSec=1min 30s
TimeoutAbortUSec=1min 30s
TimeoutStartFailureMode=terminate
TimeoutStopFailureMode=terminate
RuntimeMaxUSec=infinity
RuntimeRandomizedExtraUSec=0
WatchdogUSec=0
WatchdogTimestampMonotonic=0
RootDirectoryStartOnly=no
RemainAfterExit=no
GuessMainPID=yes
MainPID=3310
ControlPID=0
FileDescriptorStoreMax=0
NFileDescriptorStore=0
StatusErrno=0
Result=success
ReloadResult=success
CleanResult=success
UID=[not set]
GID=[not set]
NRestarts=0
OOMPolicy=stop
ExecMainStartTimestamp=Thu 2025-10-30 10:44:57 GMT
ExecMainStartTimestampMonotonic=1896974462
ExecMainExitTimestampMonotonic=0
ExecMainPID=3310
ExecMainCode=0
ExecMainStatus=0
ExecStart={ path=/usr/sbin/rpc.idmapd ; argv[]=/usr/sbin/rpc.idmapd ; ignore_errors=no ; start_time=[n/a] ; stop_time=[n/a] ; pid=0 ; code=(null) ; status=0/0 }
ExecStartEx={ path=/usr/sbin/rpc.idmapd ; argv[]=/usr/sbin/rpc.idmapd ; flags= ; start_time=[n/a] ; stop_time=[n/a] ; pid=0 ; code=(null) ; status=0/0 }
Slice=system.slice
ControlGroup=/system.slice/nfs-idmapd.service
ControlGroupId=2746
MemoryCurrent=[not set]
MemoryAvailable=infinity
CPUUsageNSec=13526000
TasksCurrent=1
IPIngressBytes=[no data]
IPIngressPackets=[no data]
IPEgressBytes=[no data]
IPEgressPackets=[no data]
IOReadBytes=18446744073709551615
IOReadOperations=18446744073709551615
IOWriteBytes=18446744073709551615
IOWriteOperations=18446744073709551615
Delegate=no
CPUAccounting=yes
CPUWeight=[not set]
StartupCPUWeight=[not set]
CPUShares=[not set]
StartupCPUShares=[not set]
CPUQuotaPerSecUSec=infinity
CPUQuotaPeriodUSec=infinity
IOAccounting=no
IOWeight=[not set]
StartupIOWeight=[not set]
BlockIOAccounting=no
BlockIOWeight=[not set]
StartupBlockIOWeight=[not set]
MemoryAccounting=yes
DefaultMemoryLow=0
DefaultMemoryMin=0
MemoryMin=0
MemoryLow=0
MemoryHigh=infinity
MemoryMax=infinity
MemorySwapMax=infinity
MemoryLimit=infinity
DevicePolicy=auto
TasksAccounting=yes
TasksMax=8751
IPAccounting=no
ManagedOOMSwap=auto
ManagedOOMMemoryPressure=auto
ManagedOOMMemoryPressureLimit=0
ManagedOOMPreference=none
UMask=0022
LimitCPU=infinity
LimitCPUSoft=infinity
LimitFSIZE=infinity
LimitFSIZESoft=infinity
LimitDATA=infinity
LimitDATASoft=infinity
LimitSTACK=infinity
LimitSTACKSoft=8388608
LimitCORE=infinity
LimitCORESoft=0
LimitRSS=infinity
LimitRSSSoft=infinity
LimitNOFILE=524288
LimitNOFILESoft=1024
LimitAS=infinity
LimitASSoft=infinity
LimitNPROC=29171
LimitNPROCSoft=29171
LimitMEMLOCK=8388608
LimitMEMLOCKSoft=8388608
LimitLOCKS=infinity
LimitLOCKSSoft=infinity
LimitSIGPENDING=29171
LimitSIGPENDINGSoft=29171
LimitMSGQUEUE=819200
LimitMSGQUEUESoft=819200
LimitNICE=0
LimitNICESoft=0
LimitRTPRIO=0
LimitRTPRIOSoft=0
LimitRTTIME=infinity
LimitRTTIMESoft=infinity
OOMScoreAdjust=0
CoredumpFilter=0x33
Nice=0
IOSchedulingClass=2
IOSchedulingPriority=4
CPUSchedulingPolicy=0
CPUSchedulingPriority=0
CPUAffinityFromNUMA=no
NUMAPolicy=n/a
TimerSlackNSec=50000
CPUSchedulingResetOnFork=no
NonBlocking=no
StandardInput=null
StandardOutput=journal
StandardError=inherit
TTYReset=no
TTYVHangup=no
TTYVTDisallocate=no
SyslogPriority=30
SyslogLevelPrefix=yes
SyslogLevel=6
SyslogFacility=3
LogLevelMax=-1
LogRateLimitIntervalUSec=0
LogRateLimitBurst=0
SecureBits=0
CapabilityBoundingSet=cap_chown cap_dac_override cap_dac_read_search cap_fowner cap_fsetid cap_kill cap_setgid cap_setuid cap_setpcap cap_linux_immutable cap_net_bind_service cap_net_broadcast cap_net_admin cap_net_raw cap_ipc_lock cap_ipc_owner cap_sys_module cap_sys_rawio cap_sys_chroot cap_sys_ptrace cap_sys_pacct cap_sys_admin cap_sys_boot cap_sys_nice cap_sys_resource cap_sys_time cap_sys_tty_config cap_mknod cap_lease cap_audit_write cap_audit_control cap_setfcap cap_mac_override cap_mac_admin cap_syslog cap_wake_alarm cap_block_suspend cap_audit_read cap_perfmon cap_bpf cap_checkpoint_restore
DynamicUser=no
RemoveIPC=no
PrivateTmp=no
PrivateDevices=no
ProtectClock=no
ProtectKernelTunables=no
ProtectKernelModules=no
ProtectKernelLogs=no
ProtectControlGroups=no
PrivateNetwork=no
PrivateUsers=no
PrivateMounts=no
PrivateIPC=no
ProtectHome=no
ProtectSystem=no
SameProcessGroup=no
UtmpMode=init
IgnoreSIGPIPE=yes
NoNewPrivileges=no
SystemCallErrorNumber=2147483646
LockPersonality=no
RuntimeDirectoryPreserve=no
RuntimeDirectoryMode=0755
StateDirectoryMode=0755
CacheDirectoryMode=0755
LogsDirectoryMode=0755
ConfigurationDirectoryMode=0755
TimeoutCleanUSec=infinity
MemoryDenyWriteExecute=no
RestrictRealtime=no
RestrictSUIDSGID=no
RestrictNamespaces=no
MountAPIVFS=no
KeyringMode=private
ProtectProc=default
ProcSubset=all
ProtectHostname=no
KillMode=control-group
KillSignal=15
RestartKillSignal=15
FinalKillSignal=9
SendSIGKILL=yes
SendSIGHUP=no
WatchdogSignal=6
Id=nfs-idmapd.service
Names=nfs-idmapd.service
Requires=rpc_pipefs.target system.slice
BindsTo=nfs-server.service
WantedBy=nfs-server.service
Before=nfs-server.service
After=rpc_pipefs.target local-fs.target system.slice systemd-journald.socket
Description=NFSv4 ID-name mapping service
LoadState=loaded
ActiveState=active
FreezerState=running
SubState=running
FragmentPath=/lib/systemd/system/nfs-idmapd.service
UnitFileState=static
UnitFilePreset=enabled
StateChangeTimestamp=Thu 2025-10-30 10:44:57 GMT
StateChangeTimestampMonotonic=1896974508
InactiveExitTimestamp=Thu 2025-10-30 10:44:57 GMT
InactiveExitTimestampMonotonic=1896968778
ActiveEnterTimestamp=Thu 2025-10-30 10:44:57 GMT
ActiveEnterTimestampMonotonic=1896974508
ActiveExitTimestamp=Thu 2025-10-30 10:44:57 GMT
ActiveExitTimestampMonotonic=1896934332
InactiveEnterTimestamp=Thu 2025-10-30 10:44:57 GMT
InactiveEnterTimestampMonotonic=1896937404
CanStart=yes
CanStop=yes
CanReload=no
CanIsolate=no
CanFreeze=yes
StopWhenUnneeded=no
RefuseManualStart=no
RefuseManualStop=no
AllowIsolate=no
DefaultDependencies=no
OnSuccessJobMode=fail
OnFailureJobMode=replace
IgnoreOnIsolate=no
NeedDaemonReload=no
JobTimeoutUSec=infinity
JobRunningTimeoutUSec=infinity
JobTimeoutAction=none
ConditionResult=yes
AssertResult=yes
ConditionTimestamp=Thu 2025-10-30 10:44:57 GMT
ConditionTimestampMonotonic=1896938460
AssertTimestamp=Thu 2025-10-30 10:44:57 GMT
AssertTimestampMonotonic=1896938467
Transient=no
Perpetual=no
StartLimitIntervalUSec=10s
StartLimitBurst=5
StartLimitAction=none
FailureAction=none
SuccessAction=none
InvocationID=fba9420d0c0241df80f2ac69f6cf392a
CollectMode=inactive

seth · 2025-10-31 20:33:41

Looks root-ish.
Ignoring the message (idmap is probably? not relevant here anyway), does the nfs server log any issues?
Can you write the directory (touch a file inside) if you completely open it 777 to the world?

elgmizik · 2025-10-31 22:06:28

Should I look somewhere else than the `journalctl -u nfs-server` log excerpt I posted earlier? Doesn't seem to throw any error here.

Yes, I can touch a file that has 777 permissions from the client.

Last edited by elgmizik (2025-10-31 22:07:28)

seth · 2025-11-01 09:28:13

So the export seems ok, either the server lacks permissions still or the id mapping is botched.

Post the servers idmapd.conf and in doubt edit the service to run "-vvvv"
Last resort would be to https://wiki.archlinux.org/title/Audit_ … ies_access some directory on the server and then trying to write it.

elgmizik · 2025-11-03 16:42:23

server's idmap.conf

[General]

Verbosity = 0
# set your own domain here, if it differs from FQDN minus hostname
Domain = noho.st

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

[Logging]
# Set to debug or info for better logging
LogLevel = debug

Here's the log now after adding the four -v flags to the idmapd service:

Nov 03 16:39:55 myserver.noho.st systemd[1]: Starting nfs-idmapd.service - NFSv4 ID-name mapping service...
Nov 03 16:39:55 myserver.noho.st rpc.idmapd[114228]: Setting log level to 4
Nov 03 16:39:55 myserver.noho.st rpc.idmapd[114228]: libnfsidmap: using domain: noho.st
Nov 03 16:39:55 myserver.noho.st rpc.idmapd[114228]: libnfsidmap: Realms list: 'NOHO.ST'
Nov 03 16:39:55 myserver.noho.st rpc.idmapd[114228]: libnfsidmap: loaded plugin /usr/lib/aarch64-linux-gnu/libnfsidmap/nsswitch.so for method nsswitch
Nov 03 16:39:55 myserver.noho.st rpc.idmapd[114228]: Expiration time is 600 seconds.
Nov 03 16:39:55 myserver.noho.st rpc.idmapd[114228]: Opened /proc/net/rpc/nfs4.nametoid/channel
Nov 03 16:39:55 myserver.noho.st rpc.idmapd[114228]: Opened /proc/net/rpc/nfs4.idtoname/channel
Nov 03 16:39:55 myserver.noho.st systemd[1]: Started nfs-idmapd.service - NFSv4 ID-name mapping service.

seth · 2025-11-03 22:04:50

The "[Logging]" group isn't documented in the manpage and Verbosity is set to 0 ?
That aside: does the journal output cover a failed attempt at writing a file?

elgmizik · 2025-11-04 09:36:22

seth wrote:

The "[Logging]" group isn't documented in the manpage and Verbosity is set to 0 ?

Mmmh, don't know where I got this [Logging] from?! And I think I set verbosity back to 0 when I saw nothing in the journal after setting it to 1 or 2.

seth wrote:

That aside: does the journal output cover a failed attempt at writing a file?

Unfortunately no, I only get this kind of thing now with verbosity -vvvv:

Nov 04 09:18:33 myserver.noho.st rpc.idmapd[692]: nfsdcb: authbuf=192.168.1.0/24 authtype=user
Nov 04 09:18:33 myserver.noho.st rpc.idmapd[692]: nfs4_uid_to_name: calling nsswitch->uid_to_name
Nov 04 09:18:33 myserver.noho.st rpc.idmapd[692]: nfs4_uid_to_name: nsswitch->uid_to_name returned 0
Nov 04 09:18:33 myserver.noho.st rpc.idmapd[692]: nfs4_uid_to_name: final return value is 0
Nov 04 09:18:33 myserver.noho.st rpc.idmapd[692]: Server : (user) id "2675" -> name "myuser@noho.st"

Indeed, `myuser` has id 2675 on the server, and 1000 on my desktop machine.

seth · 2025-11-04 13:22:11

seth wrote:

Last resort would be to https://wiki.archlinux.org/title/Audit_ … ies_access some directory on the server and then trying to write it.

elgmizik · 2025-11-05 11:00:36

Will try this as soon as I have a little bit of time, thanks for all your advice.

Just to be sure: should I try to audit access to the files on the client, the server, both?

seth · 2025-11-05 13:51:39

On the server, we know that on the client it will fail because it fails on the server - the question is: what does try to write it there and why does it fail.

elgmizik · 2025-11-05 14:57:09

Oh, just in case this wasn't clear from the previous messages: I can touch and write file while I'm connected to the server through ssh. I can also access and read them from the client with the NFS mount, I just can't write to the directories or touch the files from the client

On the server, I created an audit rule associated with a file

sudo auditctl -a always,exit -F arch=b64 -F path='/mnt/myharddrive/music/library/some_file.mp3' -F perm=rwxa -F key=file64

Then, touched the file from the server. If I look at the audit logs through `sudo ausearch -k file64 | less`, I get this:

----
time->Wed Nov  5 14:49:58 2025
type=PROCTITLE msg=audit(1762354198.903:878): proctitle=746F756368002F6D6E742F544F53484942415F4D5130314142443130302F6D757369632F6C6962726172792F42616C6F6A692F313337204176656E7565204B616E69616D612F303120476C6F7373696E6520285A6F6D626965292E6D7033
type=PATH msg=audit(1762354198.903:878): item=0 name=2F6D6E742F544F53484942415F4D5130314142443130302F6D757369632F6C6962726172792F42616C6F6A692F313337204176656E7565204B616E69616D612F303120476C6F7373696E6520285A6F6D626965292E6D7033 inode=49938647 dev=08:01 mode=0100644 ouid=2675 ogid=2675 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1762354198.903:878): cwd="/home/myuser"
type=SYSCALL msg=audit(1762354198.903:878): arch=c00000b7 syscall=56 success=yes exit=3 a0=ffffffffffffff9c a1=7ff95fa508 a2=941 a3=1b6 items=1 ppid=1859 pid=41478 auid=2675 uid=2675 gid=2675 euid=2675 suid=2675 fsuid=2675 egid=2675 sgid=2675 fsgid=2675 tty=pts1 ses=2 comm="touch" exe="/usr/bin/touch" key="file64"

If I try to touch the file from the client, nothing appears in the logs.

Sorry if I misunderstood the auditing procedure

Last edited by elgmizik (2025-11-05 14:57:35)

seth · 2025-11-05 15:24:37

Oh, just in case this wasn't clear from the previous message

No, I understood that.

If I try to touch the file from the client, nothing appears in the logs.

So the server doesn't even try to write the file at this point.
It does work when then file is 666 ?
Do you then get an audit entry?

elgmizik · 2025-11-05 15:46:28

I can touch the file from the client when it is 666, but I do not get a `touch` audit entry in this case. Only calls from `exe=/usr/bin/mpd` that does an automatic update (it is configured to do so whenever the music dir changes).

seth · 2025-11-05 16:06:37

If would not come from the touch command on the client but the nfs server

The symptoms strongly suggest the permissions / id-mapping are wrong - can you read the file when setting it 600 ?

elgmizik · 2025-11-05 16:10:27

No I can't read it when setting it to 600!

seth · 2025-11-05 21:46:38

https://unix.stackexchange.com/question … th-sec-sys
And also the note in https://wiki.archlinux.org/title/NFS#NFSv4_idmapping

Is https://wiki.archlinux.org/title/NFS#static_mapping an option?

elgmizik · 2025-11-06 09:23:16

Oh, I did not understand what these warnings in the wiki's note meant in the first place. OK, so I must admit I don't understand the use of mapping names but not permissions ?!

Yes static mapping should be OK for me, but:
- from what I understand, if I write a file from the client, the file will be written with my client's uid on the server, right? This may be a concern in the future
- I tried adding the config lines from the static mapping paragraph to the client, but I still can't touch my files from the client after remounting the volume and clearing the keyring…

Here's my client's idmapd.conf

[General]
#Verbosity = 0
# The following should be set to the local NFSv4 domain name
# The default is the host's DNS domain name.
Domain = noho.st

# In multi-domain environments, some NFS servers will append the identity
# management domain to the owner and owner_group in lieu of a true NFSv4
# domain.  This option can facilitate lookups in such environments.  If
# set to a value other than "none", the nsswitch  plugin will first pass
# the name to the password/group lookup function without stripping the
# domain off.  If that mapping fails then the plugin will try again using
# the old method (comparing the domain in the string to the Domain value,
# stripping it if it matches, and passing the resulting short name to the
# lookup function).  Valid values are "user", "group", "both", and
# "none".  The default is "none".
#No-Strip = none

# Winbind has a quirk whereby doing a group lookup in UPN format
# (e.g. staff@americas.example.com) will cause the group to be
# displayed prefixed with the full domain in uppercase
# (e.g. AMERICAS.EXAMPLE.COM\staff) instead of in the familiar netbios
# name format (e.g. AMERICAS\staff).  Setting this option to true
# causes the name to be reformatted before passing it to the group
# lookup function in order to work around this.  This setting is
# ignored unless No-Strip is set to either "both" or "group".
# The default is "false".
#Reformat-Group = false

# The following is a comma-separated list of Kerberos realm
# names that should be considered to be equivalent to the
# local realm, such that <user>@REALM.A can be assumed to
# be the same user as <user>@REALM.B
# If not specified, the default local realm is the domain name,
# which defaults to the host's DNS domain name,
# translated to upper-case.
# Note that if this value is specified, the local realm name
# must be included in the list!
#Local-Realms =

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

[Translation]

# Translation Method is an comma-separated, ordered list of
# translation methods that can be used.  Distributed methods
# include "nsswitch", "umich_ldap", and "static".  Each method
# is a dynamically loadable plugin library.
# New methods may be defined and inserted in the list.
# The default is "nsswitch".
Method = static,nsswitch

# Optional.  This is a comma-separated, ordered list of
# translation methods to be used for translating GSS
# authenticated names to ids.
# If this option is omitted, the same methods as those
# specified in "Method" are used.
#GSS-Methods = <alternate method list for translating GSS names>

#-------------------------------------------------------------------#
# The following are used only for the "static" Translation Method.
#-------------------------------------------------------------------#
[Static]

# A "static" list of GSS-Authenticated names to
# local user name mappings

myuser@noho.st = myuser
#someuser@REALM = localuser


#-------------------------------------------------------------------#
# The following are used only for the "umich_ldap" Translation Method.
#-------------------------------------------------------------------#

[UMICH_SCHEMA]

# server information (REQUIRED)
LDAP_server = ldap-server.local.domain.edu

# the default search base (REQUIRED)
LDAP_base = dc=local,dc=domain,dc=edu

Did I miss anything?

Last edited by elgmizik (2025-11-06 10:51:39)

seth · 2025-11-06 20:02:49

Did you consult

nfsidmap -l

?
[Edit: on client and server:]

cat /sys/module/nfs/parameters/nfs4_disable_idmapping

Last edited by seth (2025-11-06 20:05:59)

elgmizik · 2025-11-10 10:24:54

nfsidmap -l

returns

4 .id_resolver keys found:
  uid:root@noho.st
  gid:myuser@noho.st
  uid:myuser@noho.st
  gid:root@noho.st

Regarding the kernel module parameter, I have set it on both the client and server so that the cat command returns N on both

elgmizik · 2025-11-16 16:19:33

Well, I got it working by restricting the export to my client's IP and set all_squash + anonuid/anongid to the server's user UID/GID as stated in the wiki:

NFS expects the user and/or user group IDs are the same on both the client and server (unless Kerberos is used). Use NFSv4 idmapping or overrule the UID/GID manually by using anonuid/anongid together with all_squash in /etc/exports.

I think this statement is a little misleading. It says "use nfsv4 idmapping OR overrule the UID/GID manually", but in the first case I can't get the permissions right, whereas using these options gives me the permissions and I can still see my user's name when I `ls -l` on the client (I guess through idmapping that I had setup).

Should I edit the wiki to clarify this point?

Last edited by elgmizik (2025-11-16 16:22:13)

Arch Linux

#1 2025-10-30 12:43:28

[SOLVED] Can't write on an NFS4 volume although permissions look good

#2 2025-10-30 19:29:02

Re: [SOLVED] Can't write on an NFS4 volume although permissions look good

#3 2025-10-31 10:57:29

Re: [SOLVED] Can't write on an NFS4 volume although permissions look good

#4 2025-10-31 13:16:23

Re: [SOLVED] Can't write on an NFS4 volume although permissions look good

#5 2025-10-31 13:21:42

Re: [SOLVED] Can't write on an NFS4 volume although permissions look good

#6 2025-10-31 20:33:41

Re: [SOLVED] Can't write on an NFS4 volume although permissions look good

#7 2025-10-31 22:06:28

Re: [SOLVED] Can't write on an NFS4 volume although permissions look good

#8 2025-11-01 09:28:13

Re: [SOLVED] Can't write on an NFS4 volume although permissions look good

#9 2025-11-03 16:42:23

Re: [SOLVED] Can't write on an NFS4 volume although permissions look good

#10 2025-11-03 22:04:50

Re: [SOLVED] Can't write on an NFS4 volume although permissions look good

#11 2025-11-04 09:36:22

Re: [SOLVED] Can't write on an NFS4 volume although permissions look good

#12 2025-11-04 13:22:11

Re: [SOLVED] Can't write on an NFS4 volume although permissions look good

#13 2025-11-05 11:00:36

Re: [SOLVED] Can't write on an NFS4 volume although permissions look good

#14 2025-11-05 13:51:39

Re: [SOLVED] Can't write on an NFS4 volume although permissions look good

#15 2025-11-05 14:57:09

Re: [SOLVED] Can't write on an NFS4 volume although permissions look good

#16 2025-11-05 15:24:37

Re: [SOLVED] Can't write on an NFS4 volume although permissions look good

#17 2025-11-05 15:46:28

Re: [SOLVED] Can't write on an NFS4 volume although permissions look good

#18 2025-11-05 16:06:37

Re: [SOLVED] Can't write on an NFS4 volume although permissions look good

#19 2025-11-05 16:10:27

Re: [SOLVED] Can't write on an NFS4 volume although permissions look good

#20 2025-11-05 21:46:38

Re: [SOLVED] Can't write on an NFS4 volume although permissions look good

#21 2025-11-06 09:23:16

Re: [SOLVED] Can't write on an NFS4 volume although permissions look good

#22 2025-11-06 20:02:49

Re: [SOLVED] Can't write on an NFS4 volume although permissions look good

#23 2025-11-10 10:24:54

Re: [SOLVED] Can't write on an NFS4 volume although permissions look good

#24 2025-11-16 16:19:33

Re: [SOLVED] Can't write on an NFS4 volume although permissions look good

Board footer