> st_mode=S_IFREG|S_ISGID|0640 implies a "mandatory locking" file. knfsd
> currently refuses to touch mandatory locking files as NFS (v2 and v3 at
> least) cannot support mandatory locking. It would probably be as safe,
> and less intrusive, to allow access but simply deny all lock requests to
> a mandatory locking file, but I haven't looked into the issues very
> deeply.
Stupid question:
Why/how does nfsd tackle this? Can't knfsd just duplicate nfsd in this
respect for the time being?
> Do you know which file is being accessed? used "tcpdump -s 300" should
> help you find out. Does it "need" to have mandatory locking set?
No (as I'm not on the right machine right now) but I strongly suspect krdb
(the KDE-xrdb) is trying to load its configuration, i.e. load the KDE X
resources somewhere under $HOME/.kde/share/apps/krdb/. It's not critical (I
suppose) to just ignore mandatory locking for now.
But probably the KDE developers should also think of something here, it
makes all KDE apps unusable over kernel nfs (opening a file dialog is
enough..)
Thanks for your help!
-- _ciao, Jens_______________________________ http://www.pinguin.conetix.de · "[Microsoft] ... guarantees 99.8% NT uptime for certain hard-/software. That's exactly the 3 minutes daily that my NT server needs to reboot." -- ZDnet editorial- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/