Public bug reported: We just upgraded to Ubuntu 20.04, so we're now running version 0.8.3-1ubuntu12.1 of zfsutils-linux and related packages.
We have a backup server that's essentially rsyncing files from remote systems. After the upgrade we started getting Permission denied failures on a few files, which match a specific pattern: In a directory with a sticky bit set: /zfs# mkdir testdir /zfs# chmod a+t testdir ... which is group writable: /zfs# chmod g+w testdir ... and has an existing file: /zfs# touch testdir/test ... which has a uid which isn't present on the system: /zfs# chown 9999 testdir/test ... then an open() call with O_CREAT fails with Permission denied: /zfs# ./openat testdir/test Error opening testdir/test: Permission denied (13) Skip any of those steps and it doesn't throw the error. It's just that specific configuration of directory permissions and file ownership that seems to do it. The ./openat is a simple test case that just runs open() (so named as I was originally testing with the openat() call) and it's attached for reference. We have an rsync --inplace that gets us into that specific scenario. Dropping the --inplace works around it, FWIW, but then we lose a little space within the ZFS snapshots. ** Affects: zfs-linux (Ubuntu) Importance: Undecided Status: New ** Attachment added: "Test case" https://bugs.launchpad.net/bugs/1887727/+attachment/5393017/+files/openat.c -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1887727 Title: Permission denied opening file in a directory with a sticky bit To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1887727/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs