sysrepo: Ubuntu 20.04 LTS permission denied error
On Ubuntu 20.04, there is an error with yet unknown cause tracked in cesnet/netopeer2#621. In sysrepo it manifests in permission denied errors on most operations even when using the root user. The only solution we can suggest right now is not to use this distribution.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 19 (6 by maintainers)
Commits related to this issue
- Work around a paranoid kernel protection for sticky-bit directories Since the Linux kernel 4.19+ and systemd v241, there's a new sysctl knob which prevents users from overwriting "someone else's file... — committed to jktjkt/sysrepo by jktjkt 3 years ago
- Work around a paranoid kernel protection for sticky-bit directories Since the Linux kernel 4.19+ and systemd v241, there's a new sysctl knob which prevents users from overwriting "someone else's file... — committed to jktjkt/sysrepo by jktjkt 3 years ago
- Work around a paranoid kernel protection for sticky-bit directories Since the Linux kernel 4.19+ and systemd v241, there's a new sysctl knob which prevents users from overwriting "someone else's file... — committed to sysrepo/sysrepo by jktjkt 3 years ago
- Fix Makefile and tox configuration * Adapt to target branch "libyang1" of libyang and sysrepo dependency * Address one new pylint warning when using latest pylint's version (2.10.2) * Address s... — committed to nicolasmorini/sysrepo-python by nicolasmorini 3 years ago
- Fix Makefile and tox configuration * Adapt to target branch "libyang1" of libyang and sysrepo dependency * Address one new pylint warning when using latest pylint's version (2.10.2) * Address s... — committed to nicolasmorini/sysrepo-python by nicolasmorini 3 years ago
- Fix Makefile and tox configuration * Adapt to target branch "libyang1" of libyang and sysrepo dependency * Address one new pylint warning when using latest pylint's version (2.10.2) * Address s... — committed to nicolasmorini/sysrepo-python by nicolasmorini 3 years ago
- Fix Makefile and tox configuration * Adapt to target branch "libyang1" of libyang and sysrepo dependency * Address one new pylint warning when using latest pylint's version (2.10.2) * Run CI wo... — committed to nicolasmorini/sysrepo-python by nicolasmorini 3 years ago
- Fix Makefile and tox configuration * Adapt to target branch "libyang1" of libyang and sysrepo dependency * Address one new pylint warning when using latest pylint's version (2.10.2) * Run CI wo... — committed to nicolasmorini/sysrepo-python by nicolasmorini 3 years ago
- Fix Makefile and tox configuration * Adapt to target branch "libyang1" of libyang and sysrepo dependency * Address one new pylint warning when using latest pylint's version (2.10.2) * Run CI wo... — committed to sysrepo/sysrepo-python by nicolasmorini 3 years ago
Isn’t setting ‘sysctl fs.protected_regular=0’ an acceptable workaround for now in 20.04?
or to persist through reboots, something like this
echo “fs.protected_regular = 0” > /etc/sysctl.d/60-disable-fs-protected-regular
This is not a Ubuntu-specific issue. It’s caused by recent enough kernel (4.19+) and systemd (>= 241). The
/dev/shmdirectory has the sticky bit set, this kernel patch added support for thefs.protected_regularsysctl knob, and this knob in turn gets enabled viasystemd. As a result, one cannot useO_CREATon “somebody else’s files” on those world-writable sticky directories.I’ll follow up on a random kernel mailing list to find out if this is the expected behavior here (my personal opinion is “WTF?”).