From f2474e4850bac88740adf6744dfbfbcf7b07de2d Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 24 Aug 2021 12:25:55 -0400 Subject: [PATCH] comment --- ..._4e89c558748c370e8bbb1ef50f4cdcf7._comment | 42 +++++++++++++++++++ 1 file changed, 42 insertions(+) create mode 100644 doc/bugs/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_2_4e89c558748c370e8bbb1ef50f4cdcf7._comment diff --git a/doc/bugs/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_2_4e89c558748c370e8bbb1ef50f4cdcf7._comment b/doc/bugs/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_2_4e89c558748c370e8bbb1ef50f4cdcf7._comment new file mode 100644 index 0000000000..6e432ab5f6 --- /dev/null +++ b/doc/bugs/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_2_4e89c558748c370e8bbb1ef50f4cdcf7._comment @@ -0,0 +1,42 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 2""" + date="2021-08-24T16:01:30Z" + content=""" + +The "retrieveKeyFile resume from 0%" test +starts by writing an empty file with default permissions. +It then does the download storing to that file. + +The permission denied is happening when trying to open that file +later, to write to it. So this seems like a umask or some other +kind of permissions problem. Maybe filesystem related in some way, +if the filesystem is somehow not honoring permissions, but that would +not be my first or second guess. + +The other 2 failures shown do chain on from that +initial failure, since that test does some things that the +later tests depend on. Looking through the log, there are several other +test failures that also seem due to permissions, that all look like this, +or probably chain from this: + + add: FAIL (4.08s) + ./Test/Framework.hs:324: + unable to modify sha1foo + +And that error message happens when it's checking that the file +permissions include the write bit. + +So, your next step should be something like: + + umask + touch foo + ls -l foo + echo foo >> foo + +I tried with `umask 0222` (new files lack any write bit) but it failed a lot +earlier, while setting up the test suite. Which seems ok itself given how +restricted and weird that umask is. If the test suite overrode the umask, it +would not notice if some actual reasonable umask caused problems. But I'm +getting ahead of confirmation that it is a umask problem. +"""]]