Any info you need to addres the issue? Anyone actually checking this bug?

It has been submitted a month ago, anyone has read this???

We do read bug reports, but we need an actual developer who understands KIO and NFS well enough to check the code. If you can help with that task, please add a comment.

Hello,

Sadly I am not good enough in KIO programming (Though I have tried to read to sources). Anyway if I could I would be happy to do that:) 
I am sorry that I had been rude, but I thought KIO is something you have someone in charge of.

Confirmed here. With kde 4.9.3.
The same error message.
It took me half a day to understand that this is kde related. I was wandering until I found that mounting through command line works fine but does not work through kde/dolphin.

I am on Gentoo. Sorry that I forgot to mention earlier.

Confirmed KDE 4.10.5. Trying to set up nfs I thought it was a problem with the config, but it's a KDE problem. I can mount just fine by command line.

this is likely bug #75757, the server needs to export with the "insecure" falg, because kio operates on ports > 1024

I however run into bug #268797 now =)

Are you able to connect to the server when running dolphin as superuser (through kdesudo)? If so, it is indeed because the export doesn't have the insecure flag.

yupp.
You don't happen to have an idea on  bug #268797, do you?
There should be some debug out from the kioslave, but even redirecting to file I don't get any.

I'm currently in the process of adding NFSv3 support and also rewriting and optimising a lot of the code (it's quite bad). I will have a look and see if I can reproduce that problem :)

Okay, I just had a look, and I can reproduce it on my new NFSv3 implementation. The good news is that I have solved it already :)
Ultimately it was caused by too big buffers being sent to the server when you were sending a big file (which is why smaller files worked). However, v3 has a new call that allows you to retrieve the maximum buffer size so unlike v2 we shouldn't be using a static max buffer size.

(In reply to Thomas Lübking from comment #8)
> this is likely bug #75757, the server needs to export with the "insecure"
> falg, because kio operates on ports > 1024
> 
> I however run into bug #268797 now =)

This does not make sense to me, KIO should provide support to connect an NFS share even if it's under port 1024. For example it could ask for a root password (or sudo, or whatever). But this is just an opinion.

Also, I have tried out insecure (and  got the very same error msg back).
The same happens with root privileges.

(In reply to fathom from comment #13)

> This does not make sense to me
This actually makes a lot of sense (while i kinda fail to see the sense in NFS requiring a <1024 port by default)

> KIO should provide support to connect an NFS share even if it's under port 1024.
Can't if the server forbids and you lack permissions.

> For example it could ask for a root password (or sudo, or whatever).
Yes, but that has nothing to do with "sense" in regards of the issue but is a reasonable solution (for most nfs servers won't export insecure)
I assume the pitfall here would be that the kioslave architecture (likely) doesn't include any subprocess to leverage. If it did, one could just suid that.

(In reply to fathom from comment #14)
> Also, I have tried out insecure (and  got the very same error msg back).
How did you re-export the filesystem on the server?

> The same happens with root privileges.
I can absolutely not confirm that.
Can you mount those nfs addresses at all?

Hi,

Here is how the exports look:
/mnt/mirror     192.168.1.0/255.255.255.0(rw,anonuid=500,anongid=500,all_squash,insecure,async,no_subtree_check)
/mnt/store      192.168.1.0/255.255.255.0(rw,anonuid=500,anongid=500,all_squash,insecure,async,no_subtree_check)

Yes, it works through any other mechanism, I am regularly using it through autofs. Also it works in userspace for example with nautilus (or how gnome's filebrowser called).

(In reply to fathom from comment #14)
> Also, I have tried out insecure (and  got the very same error msg back).
> The same happens with root privileges.

If you can't access it even with root privileges I suspect something else is the problem here. I will see if I can reproduce it later using your export options.

ftr:
those flags seem no problem here (wasn't squashing, did fsid=root, that means NFSv4, yes) - at least reg. this error message.
I get the one of bug #268797 the moment I attempt to open the exported directory.

Okay, so I've tried to reproduce this without any luck. I do know that it's the MOUNTPROC_MNT call that fails, but since there is no debug output in the code that tells you what the call returns it's difficult to say what the reason could be (it could be something other than an actual authentication error, this needs to be fixed to output the actual result).
Does the nfs server output anything when you try to browse the nfs share? It should say something along the lines of: "Authenticated mount request from IP for MOUNTPATH".

@fathom: What is the ip address of the client and the server? I was able to reproduce this by typing another ip/netmask in the exports file.

Hi,

The NFS server says this:
szept 21 21:32:58 ami unfsd[1439]: 192.168.1.198 attempted mount with unsupported protocol version

The clients are between 192.168.1.50 and 250 (this is the DHCP range on the local LAN), and the server is 183 at the end. 

What do you mean by typing other ip/netmask?

Aha, you seem to be using unfs3, which only supports NFSv3 (I think most NFS servers are backwards compatible, even though the protocol is not). The kio module as of right now is only compatible with an NFSv2 server.
I am able to reproduce this using that server, but like I said above I have almost finished implementing v3 support in the kio module, and I can confirm that unfs3 works fine now.

That's woinderful, I hope it will be pushed to mageia also soon:) Thanks!

Git commit 1f13cf8b4c5ff5ac6a2c131a89c19c7e77c0194f by Mathias Tillman.
Committed on 16/10/2014 at 10:15.
Pushed by mathiastillman into branch 'master'.

Added support for NFSv3, major refactoring, fixed bugs.

REVIEW: 120343
Related: bug 268797

M  +1    -1    nfs/CMakeLists.txt
M  +2    -2    nfs/README
M  +0    -2    nfs/TODO
M  +576  -1324 nfs/kio_nfs.cpp
M  +169  -69   nfs/kio_nfs.h
D  +0    -353  nfs/mount_xdr.c
M  +4    -0    nfs/nfs.protocol
D  +0    -699  nfs/nfs_prot.h
D  +0    -886  nfs/nfs_prot_xdr.c
A  +1858 -0    nfs/nfsv2.cpp     [License: LGPL (v2+)]
A  +103  -0    nfs/nfsv2.h     [License: LGPL (v2+)]
A  +2195 -0    nfs/nfsv3.cpp     [License: LGPL (v2+)]
A  +114  -0    nfs/nfsv3.h     [License: LGPL (v2+)]
R  +71   -158  nfs/rpc_mnt2.h [from: nfs/mount.h - 051% similarity]
R  +0    -0    nfs/rpc_mnt2.x [from: nfs/mount.x - 100% similarity]
A  +277  -0    nfs/rpc_mnt2_xdr.c     [License: UNKNOWN]  *
A  +168  -0    nfs/rpc_mnt3.h     [License: UNKNOWN]  *
A  +147  -0    nfs/rpc_mnt3_xdr.c     [License: UNKNOWN]  *
A  +488  -0    nfs/rpc_nfs2_prot.h     [License: UNKNOWN]  *
R  +0    -0    nfs/rpc_nfs2_prot.x [from: nfs/nfs_prot.x - 100% similarity]
A  +699  -0    nfs/rpc_nfs2_prot_xdr.c     [License: UNKNOWN]  *
A  +1330 -0    nfs/rpc_nfs3_prot.h     [License: UNKNOWN]  *
A  +908  -0    nfs/rpc_nfs3_prot.x
A  +1908 -0    nfs/rpc_nfs3_prot_xdr.c     [License: UNKNOWN]  *

The files marked with a * at the end have a non valid license. Please read: http://techbase.kde.org/Policies/Licensing_Policy and use the headers which are listed at that page.


http://commits.kde.org/kio-extras/1f13cf8b4c5ff5ac6a2c131a89c19c7e77c0194f

Hello,
Thank you very much for your nice efforts. Can this fix be implemented in the current kde4 through a patch? Or it would be only for kde5?  I wanted to report this to the Gentoo bugs and request them to include this fix in their portage. Would it be possible?

I will have a look at backporting it to KDE4, but I can't promise anything.

@Kete, I've submitted a review request for KDE4 here: https://git.reviewboard.kde.org/r/120761/

Thank you so much!