chown linked file systems

[Raymond Ford]

I receive the folllowing message in the syschk file:

SERVER: TESTFILEPERMS--File Access (see /usr/sup/.security/lib/fileperms)
-------------------------------------------------------------------------------
lrwxr-xr-x 1 root sys 15 Oct 5 2001 /opt/langtools -> /opt2/langtools
Should be: owner=bin

I've tried numerous ways but cannot properly chown this linked file. Looking in fileperms I see that bin is listed as owning these directories. Seeing that /opt is 97% full and /opt2 only 10%, I presume the link to be hard. Then I see that /opt is on /dev/vg20/lvol4 while /opt2 resides on /dev/vg20/lvol01. In that hard links must exist in the same file system, I now presume the link to be symbolic. Must I unlink the directories before performing chown? Which directory should the command be issued from? I've tried the chown command as root, bin, and sys. Thank-you all in advance.

[harry d brown jr]

Terrence,


Man ln

Symbolic links are created with the ownership of the creator and the permissions are of the creator's current umask. Once created, the symbolic link ownership and permissions will not change, since the mode and ownership of the symbolic link is ignored by the system.




live free or die
harry

[U.SivaKumar_2]

hi,
if the link is hard , ll command will not
show /x/y -> /x/y1
have you tried chown the original directory first not the link.

regards,
U.SivaKumar

[James R. Ferguson · Accepted solution]

Hi:

The ownership of a symbolic (soft) link doesn't matter. The ownership of the file pointed to by the link is the important factor.

Hard links cannot cross mountpoints, and this is one value of using a symbolic link.

If you really care about making your symbolic link's ownership the same as the file to which it points, use:

# chown -h ...

See the man pages for more information.

Regards!

...JRF...

[harry d brown jr]

Here's a quick display of what Terrence is seeing:

# ls -l | grep opt
dr-xr-xr-x 49 bin bin 1024 Oct 24 09:18 opt
lrwxrwxrwx 1 root sys 4 Apr 18 07:43 opt2 -> /opt
# rm /opt2
# ls -l | grep opt
dr-xr-xr-x 49 bin bin 1024 Oct 24 09:18 opt
# ln -s /opt /opt2
# ls -l | grep opt
dr-xr-xr-x 49 bin bin 1024 Oct 24 09:18 opt
lrwxrwxrwx 1 root sys 4 Apr 18 07:49 opt2 -> /opt
# chown bin:bin /opt2
# ls -l | grep opt
dr-xr-xr-x 49 bin bin 1024 Oct 24 09:18 opt
lrwxrwxrwx 1 root sys 4 Apr 18 07:49 opt2 -> /opt
#


This is an example of a hard link:

# touch ttt
# ln ttt yyy
# ls -l | grep -e ttt -e yyy
-rw-rw-rw- 2 root sys 0 Apr 18 07:49 ttt
-rw-rw-rw- 2 root sys 0 Apr 18 07:49 yyy
# chown bin:bin yyy
# ls -l | grep -e ttt -e yyy
-rw-rw-rw- 2 bin bin 0 Apr 18 07:49 ttt
-rw-rw-rw- 2 bin bin 0 Apr 18 07:49 yyy
#

Of which Terrence has a SOFT link.

live free or die
harry

[Darrell Allen]

Hi Terrence,

Although the ownership and perms on a symlink don't really matter, if you want to change it you have to:
-delete the symlink
-become the user you want to own the symlink
-set umask as desired
-re-create the symlink

You must also ensure the user (bin in your case) has write permissions on the directory in which the symlink resides. If you chmod the directory before creating the symlink, you should chmod it back to what it was when you finish.

This process is not very difficult but it is rather silly to have to do it for something that doesn't really matter.

Here's a little more info on links. Consider the following:

# ll file*
-rw-r--r-- 2 root sys 5 Apr 18 09:03 file
-rw-r--r-- 2 root sys 5 Apr 18 09:03 file.hardlink
lrwxr-xr-x 1 root sys 4 Apr 18 09:03 file.symlink -> file

Note the "->". That's an indicator it's a symlink. Also, the "l" at the beginning of the line means it's a symlink.

Note the listing for file and file.hardlink. They are identical. The "-" at the beginning of the line means it's a regular file. The "2" between the permissions and the owner indicate there are 2 links to this file. That means one of them was created as a hard link to the first. They are actually 2 different directory entries pointing to the same inode. That is verified using the "-i" (show inodes) argument of ll:

# ll -i file*
5263 -rw-r--r-- 2 root sys 5 Apr 18 09:03 file
5263 -rw-r--r-- 2 root sys 5 Apr 18 09:03 file.hardlink
5993 lrwxr-xr-x 1 root sys 4 Apr 18 09:03 file.symlink -> file

Note the inodes. 5263 is the inode for both file and file.hardlink.

Note the inode for file.symlink. It's different because symlinks are separate directory entries with their own inodes.

Last thing. Note the size of file.symlink. It's 4 bytes. That's because the contents of the symlink are actually the name of the file it points to (though you won't see that with usual UNIX commands). file.symlink points to "file", a name which is 4 bytes long.

Darrell

[Raymond Ford]

Darryl: You get a 10 for helping me to remember how much I have forgotten. Some luck must have been involved in that the chown -h command was effective on its own. I wanted to get the ownership issue straight simply to have to keep from looking at an "error" message every morning in an email;-)

[harry d brown jr]

Damn, I need a take away points here - I should have rtfm.

live free or die
harry

[Darrell Allen]

Well, it wasn't luck! Ya'll just took me to school!

Forget all the stuff I said about deleting the symlink, etc. I didn't know about "chown -h".

Obviously, I didn't pay enough attention to JRF's answer and simply wrote about what I've done in the past.

Definitely N/A (wish it could be -10) for this reply.

Darrell (who still learns much more from these forums than I share)