We should consider using FUSE for our local drives instead of the kernel's NFS client. This would make things a lot simpler since we wouldn't have to rely on mount being setuid and well behaved. Control over the client would also mean we could add features like better handling of disconnected sessions (no horrible hangs) and dynamic discovery of exported paths. The big downside is requiring FUSE. On Linux this isn't a problem as it's been in the kernel since 2.6.14. Given our other requirements, every distribution that supports ThinLinc should have FUSE. We'll have to drop support for local drives on Solaris though, or keep the kernel method there. There is also some more overhead with FUSE. But on the other hand, we have performance issue with unfsd already and having control of both the client and server could give us a better chance of solving those.
There is an existing implementation of NFS over FUSE that we can use as a base: https://github.com/openunix/hsfs I did a brief test and it mostly works. There are a few warts to fix, but I can browse the file tree and open files just fine.
Actually, Solaris doesn't have support for local drives right now (bug 630).
(In reply to comment #0) > This would make things a lot simpler since we wouldn't have to rely on > mount being setuid and well behaved. This is incorrect. We ship our own setuid programs to handle the transition to root. But we could get rid of them with a FUSE based approach.
(In reply to comment #1) > There is an existing implementation of NFS over FUSE that we can use as a base: > > https://github.com/openunix/hsfs > > I did a brief test and it mostly works. There are a few warts to fix, but I can > browse the file tree and open files just fine. The project above has not been updated for a long time, but this one also looks promising: https://github.com/sahlberg/fuse-nfs
*** Bug 1893 has been marked as a duplicate of this bug. ***
