Is there an RFC somewhere that requires NFS errors to be completely opaque?
* 2 Fedora 33 systems on the same subnet (172.31.248.0/24). * NFS client is 172.31.248.2; NFS server is 172.31.248.3 * /etc/exports on server contains /srv/upscale_data 172.31.248.0(rw,no_subtree_check,no_root_squash,insecure)
$ sudo mount -vvvv -t nfs4 172.31.248.3:/srv/upscale_data /mnt/upscale mount.nfs4: timeout set for Thu Feb 25 18:16:45 2021 mount.nfs4: trying text-based options 'vers=4.2,addr=172.31.248.3,clientaddr=172.31.248.2' mount.nfs4: mount(2): Permission denied mount.nfs4: trying text-based options 'vers=4,minorversion=1,addr=172.31.248.3,clientaddr=172.31.248.2' mount.nfs4: mount(2): Permission denied mount.nfs4: trying text-based options 'vers=4,addr=172.31.248.3,clientaddr=172.31.248.2' mount.nfs4: mount(2): Permission denied mount.nfs4: access denied by server while mounting 172.31.248.3:/srv/upscale_data
Wireshark shows that the client is sending:
Credentials Flavor: AUTH_UNIX (1) ... UID: 0 GID: 0
And the server responds with:
Reject State: AUTH_ERROR (1) Auth State: bad credential (seal broken) (1)
The server is logging ABSOLUTELY NOTHING in the journal, dmesg, or anywhere else (as far as I can tell).
Any ideas how I can figure out what is going on?
On 2/26/21 8:20 AM, Ian Pilcher wrote:
172.31.248.0(rw,no_subtree_check,no_root_squash,insecure)
^ | /24
Aargh! I wasted a couple of hours on this last night. Amazing how seeing something in a different context enables one to spot the error.
I stand by my position that NFS mount errors are almost sadistically useless.
On Fri, 26 Feb 2021 at 10:43, Tom Horsley horsley1953@gmail.com wrote:
On Fri, 26 Feb 2021 08:33:54 -0600 Ian Pilcher wrote:
I stand by my position that NFS mount errors are almost sadistically useless.
Not enough scope. Almost all linux errors are sadistically useless :-).
At some point, RFC's need to address error reporting and diagnostics. There is also Java, which spews out 10^2 lines of tracing data with nothing to highlight the line that has the key to the problem.
I suspect the compiler work was driven by academia wanting to reduce the amount of time wasted in student training to deal with useless error messages.
With much of linux development being done by companies that sell support, better error reporting would make it easier for organizations to decide they don't need to pay for support.
On Fri, 2021-02-26 at 13:53 -0400, George N. White III wrote:
At some point, RFC's need to address error reporting and diagnostics. There is also Java, which spews out 10^2 lines of tracing data with nothing to highlight the line that has the key to the problem.
I suspect the compiler work was driven by academia wanting to reduce the amount of time wasted in student training to deal with useless error messages.
With much of linux development being done by companies that sell support, better error reporting would make it easier for organizations to decide they don't need to pay for support.
I remember one of our lecturers are college commenting how their Data General mainframe put out such a large amount of information in the error messages that it's almost too user friendly.
However, as well as the explanatory comment that you could actually read and understand, it would pop up the offending line of code with the error and park the cursor either at the last point it could cope with, or the first point it objected to (I can't remember back 25+ years). It did make it a lot easier to debug than computers that spew up: error #456.865 your turn, now...
Reminds me of the opaque error code that a friend's Windows computer spewed up when it fell into a nervous breakdown during an attempted update, and nothing further could be done with it until we fixed the unknowable error. We had to look up the code on another computer, and all the damn thing wanted was for us to correctly set the clock. It could have said that. It could have set the clock itself, it was online (and if windows used GMT/UTC it wouldn't matter what the timezone was).
On Sat, 27 Feb 2021 at 01:38, Tim via users users@lists.fedoraproject.org wrote:
On Fri, 2021-02-26 at 13:53 -0400, George N. White III wrote:
At some point, RFC's need to address error reporting and diagnostics. There is also Java, which spews out 10^2 lines of tracing data with nothing to highlight the line that has the key to the problem.
I suspect the compiler work was driven by academia wanting to reduce the amount of time wasted in student training to deal with useless error messages.
With much of linux development being done by companies that sell support, better error reporting would make it easier for organizations to decide they don't need to pay for support.
I remember one of our lecturers are college commenting how their Data General mainframe put out such a large amount of information in the error messages that it's almost too user friendly.
However, as well as the explanatory comment that you could actually read and understand, it would pop up the offending line of code with the error and park the cursor either at the last point it could cope with, or the first point it objected to (I can't remember back 25+ years). It did make it a lot easier to debug than computers that spew up: error #456.865 your turn, now...
Reminds me of the opaque error code that a friend's Windows computer spewed up when it fell into a nervous breakdown during an attempted update, and nothing further could be done with it until we fixed the unknowable error. We had to look up the code on another computer, and all the damn thing wanted was for us to correctly set the clock. It could have said that. It could have set the clock itself, it was online (and if windows used GMT/UTC it wouldn't matter what the timezone was).
Global businesses are driven by creating large ecosystems that depend on the success of the business's products. Microsoft, Sony, Samsung, Apple, Deere, Caterpillar, auto makers, Airbus, and Boeing all are examples.
Opaque error codes are a key element in the commercial success of the Windows ecosystem. A huge number of IT support staff with certifications in Windows admin are paid to do many trivial tasks because they were taught to deal with opaque error codes. The same staff recommend Windows to management even when there are much better solutions to a problem with linux or macOS. It also explains why Microsoft often makes gratuitous tweaks to standard protocols.
-
George N. White III -
Ian Pilcher -
Tim -
Tom Horsley