Operation not permitted when creating hard link (but soft link works)

I'm trying to create a hard link but get an error message "Operation not permitted"

tikey@helios64:/data/$ ln /data/dir1/img1.jpg /data/dir2/
ln: failed to create hard link '/data/dir2/img1.jpg' => '/data/dir1/img1.jpg': Operation not permitted

By adding a -s to the command, I can, however, create a softlink. I can also copy the file. So my user has permission to create files in the directory.

Why do I get a permission error when trying to create the hard link and what can I do to prevent it?

Edit - Additional information based on some answers:

The filesystem is ext4 and there is also a bind mount of dir1 on /srv (but unmounting /srv/dir1 does not make any difference):

/dev/md127 on /data type ext4 (rw,relatime,stripe=256)
/data/dir1 on /srv/dir1 type fuse (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other)

The device is set up as raid 5:

md127 : active raid5 sdc[1] sdb[2] sdd[0] 7813772288 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU] bitmap: 0/30 pages [0KB], 65536KB chunk

lsattr for the file shows:

tikey@helios64:/data$ lsattr dir1/img1.jpg
--------------e------- dir1/img1.jpg

2

3 Answers

The provided answers got me on the right track - thanks. The problem was the ownership of the file. The file belongs to a user id that doesn't exist anymore.

tikey@helios64:/data/dir2$ ls -la ../dir1/
total 146500
drwxrwxr-x+ 2 tikey users 4096 Jan 30 11:41 .
drwxrwxr-x+ 4 tikey users 4096 Jan 30 11:10 ..
-rw-r--r--+ 2 tikey tikey 6414300 Jan 30 11:41 copy.jpg
-rw-r--r--+ 1 1011 1011 6414300 Nov 20 02:39 img1.jpg

That's why after copying the file to copy.jpg the hard-link could be created. After changing the ownership of img1.jpg, also the hard-link to img1.jpg can be created.

As pointed out in the comments, this behavior can be configured, see this answer on Unix&Linux SE. To check which behavior is configured, check /proc/sys/fs/protected_hardlinks.

tikey@helios64:/data$ sudo cat /proc/sys/fs/protected_hardlinks
1

If it reveals 1, it means that - among other conditions - the filesystem UID of the process creating the link must match the owner (UID) of the target file

2

^{Note: this answer had been written before the OP used lsattr and showed that the premise of the answer does not apply to their specific case. Still I think immutability is a sane hypothesis in general. The answer stands for future users for whom it may be useful.}

---

It may be the file is immutable. Run lsattr /data/dir1/img1.jpg to confirm. The presence of i means "immutable".

From man 1 chattr:

A file with the i attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file, most of the file's metadata can not be modified, and the file can not be opened in write mode. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

You clear the i attribute with

chattr -i /data/dir1/img1.jpg

but the mentioned capability is required, so most likely you will need sudo. Before removing the attribute it's good to think why the attribute is there. If you need to set it back: chattr +i …. Note this changes the metadata of the actual file (think: inode), not of its directory entry (name, path); so if you manage to create a hardlink after chattr -i and then chattr +i the original path, then your hardlink will become immutable because it's the same file.

1

Note that this says Operation not permitted rather than Permission denied.

Besides permissions, there are several reasons why a hard link can't be made:

• Hard links must be for files on the same filesystem. (But this usually says Invalid cross-device link
• Only some filesystems (such as unix filesystems) support hard links. If I try to hard link a file on an msdos/vfat filesytem, I get Operation not permitted
• Directories can't be hard linked, but this gives hard link not allowed for directory

So likely the filesystem you are trying to hard link on doesn't support hard links for this file for some reason.

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password Submit

Post as a guest

Post Your Answer Discard

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy