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 Kernel Packages, which is subscribed to zfs-linux in Ubuntu. https://bugs.launchpad.net/bugs/1887727 Title: Permission denied opening file in a directory with a sticky bit Status in zfs-linux package in Ubuntu: New Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1887727/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp