Pulp2 sets 644 on the files which makes it impossible for the group to create hard links
These are the current permissions on the files in pulp2
ll /var/lib/pulp/content/units/rpm/ff/9be87993b8e77a5d71ecd04cbbaa7a0386d01a068e3365e05eba20836ecee9/ total 4 -rw-r--r--. 1 apache pulp 1869 Oct 20 16:53 whale-0.2-1.noarch.rpm
Pulp group can only read the file, however if you want to create a hard link you need to have write permission on the file. Pulp tries to create a hard link and fails. This blocks migration.
Taught pulp-workers to have a umask of 002 instead of 022.
#4 Updated by ggainey about 1 year ago
See https://unix.stackexchange.com/questions/377676/why-can-i-not-hardlink-to-a-file-i-dont-own-even-though-i-can-move-it for an explanation of all the things that have to be true, before one can make a hard-link to a file. On a CentOS7 box (for example), 'protected hardlinks' is 'true':
$ uname -r 3.10.0-1127.el7.x86_64 $ sudo cat /proc/sys/fs/protected_hardlinks 1
The crux of the problem in the migration case, is that Pulp3 (running as the 'pulp' user) wants to make a hard-link to a file created by Pulp2 (running as the 'apache' user). The apache daemon runs with a UMASK of 022, which means it creates files with permissions 644. This results in Pulp3 failing to create hardlinks, since the 'pulp' user in the 'pulp' group needs to have write-access, and only the 'apache' user does.
Fixing this requires us to change the context in which pulp-code is running under the apache user, to have a UMASK of 002.
Please register to edit this issue