chown: changing ownership of `.': Invalid argument
Solution 1
The /commun
file system is mounted from a remote server, and the error message suggests that is could be an nfsv4 mount (the same for earlier nfs versions is Permission denied). By default the remote file server will map remote root
user to a nobody
account so it cannot change the file ownership.
The easiest solution may be to use the local lindenb
account to create the directories under the /commun
directory. So as root
sudo -u linedb mkdir -p /commun/data/users/lindenb
If that doesn't work then there may be some id mapping taking place so you may have to mkae the directories on the server xxx.xx.xxx.xxx
and change the ownership/permissions there.
Solution 2
mount -t nfs -o vers=3 SERVER:PATH MOUNT_PATH
This worked for me.
Solution 3
This is indeed a NFS4 issue. You may have to consider rpc.idmapd the NFS4 mapping daemon in order to resolve such issues especially if lots of users will need the correct mapping between the client and the NFS server. Note that NFS3 (in CentOS < 6 for example) did not use a mapping daemon.
Related videos on Youtube
mobius
Updated on September 18, 2022Comments
-
mobius almost 2 years
I'm trying to install some new files on our new server while our sysadmin is in holidays:
Here is my
df
# df -h Filesystem Size Used Avail Use% Mounted on /dev/sdb3 273G 11G 248G 5% / tmpfs 48G 260K 48G 1% /dev/shm /dev/sdb1 485M 187M 273M 41% /boot xxx.xx.xxx.xxx:/commun 63T 2.2T 61T 4% /commun
as root , I can create a new directory and run
chown
under /home/lindenb# cd /home/lindenb/ # mkdir X # chown lindenb X
but I cannot run the same command under /commun
# cd /commun/data/users/lindenb/ # mkdir X # chown lindenb X chown: changing ownership of `X': Invalid argument
why ? how can I fix this ?
updated:
mount:
/dev/sdb3 on / type ext4 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) tmpfs on /dev/shm type tmpfs (rw) /dev/sdb1 on /boot type ext4 (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) xxx.xx.xxx.xxx:/commun on /commun type nfs (rw,noatime,noac,hard,intr,vers=4,addr=xxx.xx.xxx.xxx,clientaddr=xxx.xx.xxx.xxx)
version:
$ cat /etc/redhat-release CentOS release 6.3 (Final)
-
jwbensley over 11 yearsType
mount
and paste the output of this in your question. Also, what OS are you on? -
jwbensley over 11 yearsI'm not very knowledgeable on NFS; But seeing as /commun/data/users/lindenb/ is not a local directory on your machine, but a network share accessed via NFS, I would start by examining your permissions on the NFS server (which is out of my knowledge scope)
-
-
mobius over 11 yearsthanks but that didn't work
sudo -u lindenb mkdir -p /commun/data/users/TMP mkdir: cannot create directory
/commun/data/users/TMP': Permission denied` -
DaveG over 11 yearsYour point about NFSv4 is a red herring but I'd agree with the rest of the answer as correct.
-
user9517 over 11 years@DaveG: why is that ? If I try and chown a directory as root on an NFSv4 mount I get exactly the same error message as the OP and if I switch to NFSv3 I get Permission Denied so it's something to do with it and the way it interacts with user ids.
-
DaveG over 11 yearsBecause root gets squashed on NFSv3 as well therefore the error message might be different but he'd still be unable to create the directory as the root user.
-
user9517 over 11 years@DaveG: Right, yes, I was tailoring the answer to the OPs environment rather than a generic NFS but hey.
-
ank over 11 yearsOf course there is an exports option that fixes such condition: no_root_squash (which I do not recommend unless you are ready to take the risks or are prepared for them).