Change permissions for a symbolic link
You can make a new symlink and move it to the location of the old link.
ln -s <new_location> npm2
mv -f npm2 npm
That will preserve the link ownership. Alternatively, you can use chown
to set the link's ownership manually.
chown -h myuser:myuser npm
On most systems, symlink permissions don't matter. When using the symlink, the permissions of the components of symlink's target will be checked. However, on some systems they do matter. MacOS requires read permission on the link for readlink
, and NetBSD's symperm
mount option forces link permissions checks on read and traversal. On those systems (and their relatives, including FreeBSD and OpenBSD) there is a equivalent -h
option to chmod
.
chmod -h 777 npm
When you try to use chmod
to set the link's permissions, the actually you do is to set the permissions of the link's target.The link's permissions are meaningless.
When you have a link like:
link -> foo/bar
and want to change it to:
link -> new/target
There are two cases to consider:
foo/bar
is not a directory or doesn't exist or you don't have search access tofoo
. Thenln -s new/target link
will fail because
link
already exists, but you can overcome that by using the standard:ln -fs new/target link
foo/bar
is a directory (and you have search permission tofoo
to be able to determine thatfoo/bar
is a directory). In that case, when you do:ln -s new/target link
or
ln -fs new/target link
That's understood as creating a new
target
symlink inside thelink
directory (link
is a directory because it's a symlink to thefoo/bar
directory). So you'll actually create a:foo/bar/target -> new/target
To overcome that, GNU
ln
has a-T
option for the link name to always be considered as link name, and not as a directory to create the link(s) in. So, with GNUln
:ln -fsT new/target link
will work. Like before, it will remove the original
link
symlink and create it anew withnew/target
as the target (and the process' euid and egid as the owner).GNU
ln
also has a-n
option. It works like-T
except whenlink
is actually a real directory in which case it will still create the symlink inside that directory (instead of failing with an error).Portably, your best option is to remove the link first and then recreate it:
rm -f link && ln -s new/target link
On most systems, permissions on symlinks are ignored and generally fixed to rwxrwxrwx
.
On systems where symlink permissions matter (like OS/X where you need read permission to a symlink to be able to resolve its target), there's generally a way to change them (chmod -h
on OS/X).
Ownership, while like above not relevant for access to the file pointed to by the symlink on most systems, can have some other relevance wrt the t
bit of the parent directory or quotas...) and there's a standard command to change it:
chown -h user[:group] the-link
chgrp -h group the-link