10

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
Thomas
  • 341
  • 1
  • 3
  • 11
  • 3
    What is the type of the filesystem? What mount options are in use? The relevant line from the output of `mount` may be enough to answer this. – Kamil Maciorowski Jan 29 '22 at 22:56
  • The Filesystem is ext4 /dev/md127 on /data type ext4 (rw,relatime,stripe=256) There also is a bind mount of dir1 - in case that matters: /data/dir1 on /srv/photo_share type fuse (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other) – Thomas Jan 29 '22 at 23:11

3 Answers3

6

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.

user10489
  • 1,173
  • 1
  • 5
  • 10
6

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

Thomas
  • 341
  • 1
  • 3
  • 11
  • 2
    Probably `sudo cat /proc/sys/fs/protected_hardlinks` yields `1`. Insight in [this answer on Unix&Linux SE](https://unix.stackexchange.com/a/377719/108618). – Kamil Maciorowski Jan 30 '22 at 11:10
  • 1
    Indeed, thanks for the hint and thanks for the link - very useful. I've added it to the answer. – Thomas Jan 30 '22 at 12:46
3

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.

Kamil Maciorowski
  • 69,815
  • 22
  • 136
  • 202
  • Thanks for the quick answer. I didn't know about this but checking the file with lsattr reveals that in my case this was not the problem: --------------e------- img1.jpg – Thomas Jan 29 '22 at 22:44