Unix & Linux Asked on November 23, 2021
My direcotrory is root:
pwd
/
I have the following dir:
drwxrwxrwx 4 root root 81920 Jun 4 09:25 imr_report_repo
NOTE: imr_report_repo is an NFS share.
Here is the fstab listing for imr_report_repo:
netapp1:/imr_report_repos_stage /imr_report_repo nfs rw,bg,actimeo=0,nointr,vers=3,timeo=600,rsize=32768,wsize=32768,tcp 1 1
d imr_report_repo
A file within mount:
$ ls -al
-rw-r--r-- 1 502 502 1273 Mar 21 2013 imr1_test.txt
The UID 502 does not exist. If we add that UID/GID locally:
$ groupadd -g 502 jimmy
$ useradd -g 502 -u 502 jimmy
It now shows up:
$ ls -al
-rw-r--r-- 1 jimmy jimmy 1273 Mar 21 2013 imr1_test.txt
Now change to root:
$ su -
$ chown oracle:oinstall imr1_test.txt
chown: changing ownership of `imr1_test.txt': Operation not permitted
For other people who encounter the same error, you might want to unlock your files if you have locked it before. Run this on the directory your folder is located at.
chattr -R -i yourFolderName
Doing so will allow you to change ownership and edit the files inside.
Answered by Justine M. on November 23, 2021
on nfs host
nano /etc/exports
/share ip_of_client(rw,no_root_squash)
exit
exportfs -a
mount
mount -t nfs host:/folder <mnt location>
From RHEL
By default, NFS shares change the root user to the nfsnobody user, an unprivileged user account. This changes the owner of all root-created files to nfsnobody, which prevents uploading of programs with the setuid bit set.
If no_root_squash is used, remote root users are able to change any file on the shared file system and leave applications infected by Trojans for other users to inadvertently execute.
Answered by thistleknot on November 23, 2021
As slm comment above said,
It's typically the case that the local root user on NFS clients is disallowed from performing these types of activities on NFS mounted shares
The feature used is called rot squash. More information here. In my case, the only way was to login to disable to root squash for this particular server and enable it back later.
A similar situation you will encounter if you use docker container with volumes and the container runs with a unprivileged user (e.g. USER apache). So the idea of the NFS mountpoints to be r/w only by the owner, and not by root is a common security practice.
Answered by azbarcea on November 23, 2021
A NetApp NFS server will, by default, change the credentials of the root user on a client into uid 65534 on the server, so operations like chown will fail. To change this, edit the export list on the filer so that the line for the filesystem has the parameter root=clientid, where clientid is the IP address or hostname of the client that you want to have root access to that filesystem. Then run exportfs -a if you're using the command line interface on the filer.
Answered by Mark Plotnick on November 23, 2021
It's typically the case that the local root user on NFS clients is disallowed from performing these types of activities on NFS mounted shares. NetApp appears to add a bit of a twist on this as follows:
/etc/nsswitch.conf file to determine the corresponding UID to be assigned by the anon option.So from the looks of it the NetApp NFS share has the default option, #1. You could confirm this by touching a file on the NFS share as root and seeing what ID results from doing this.
You should be able to see the NFS share's exported options using mount -v on your NFS client.
$ mount -v
...
mulder:/export/raid1/home/sam on /home/sam type nfs (rw,intr,tcp,nfsvers=3,rsize=16384,wsize=16384,addr=192.168.1.1)
Answered by slm on November 23, 2021
Usually root does not have special permissions on NFS shares. On the contrary: root is mapped to an ordinary user (i.e. does not even have "normal" read and write access to root files).
You must run chown on the NFS server.
Answered by Hauke Laging on November 23, 2021
Get help from others!
Recent Answers
Recent Questions
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP