Oops. Disregard my last message, which didn't contain anything new. I
slipped on the keys.
According to joost witteveen:
> And /var/spool/cron/atjobs is mounted over nfs?
Yes, but it's /var that's mounted. On the client (kant, descartes is the
server):
kant:~> mount
[...]
descartes.dcd.se:/var/clients/kant/var on /var type nfs
(rw,rsize=8192,wsize=8192,addr=192.168.1.1)
[...]
> Strange, I see (on the client):
>
> rulvsa:/home/joostje/tmp# ls -al root/file
> ls: root/file: Permission denied
>
> with /home/joostje/tmp mountd via nfs. (At the moment I've got the
> no_root_squash removed again, but it was the same with it enabled).
Are you sure that you restarted all the necessary deamons?
> On the server:
> rulcmc:/tmp# ls -al root
> total 9
> drwx------ 2 root root 1024 Sep 28 12:43 .
> drwxrwxrwt 24 root root 8192 Sep 28 15:41 ..
> -rw-r--r-- 1 root root 0 Sep 28 12:43 file
>
> > > Yes, this looks as a bug to me.
> >
> > How do I find where it is so I can fix it? Do you think it's libc or nfsd?
So now, I have TWO problems? Oh, dear!
> Well, what _I_ see surely comes from nfsd. (netstd source).
> running nfsd with
> /usr/sbin/rpc.nfsd -F -d call
> clearly showed that it refused to serve /tmp/root/file (result: 13,
> which is access denied). But you seem to see something different
> (if /var/spool/cron/atjobs is mounted over nfs, apparetnly ls
> can see it).
Part of nfsd log while doing "ls -la /var/spool/cron/atjobs/" as root on
the client:
[...]
nfsd[3338] 09/28/97 16:13 lookup [1 97/9/28 16:13:17 kant 0.0+0]
fh:/var/clients/kant/var/spool/cron n:atjobs
nfsd[3338] 09/28/97 16:13 new_fh = /var/clients/kant/var/spool/cron/atjobs
nfsd[3338] 09/28/97 16:13 result: 0
nfsd[3338] 09/28/97 16:13 getattr [1 97/9/28 16:13:17 kant 0.0+0]
/var/clients/kant/var/spool/cron/atjobs
nfsd[3338] 09/28/97 16:13 result: 0
nfsd[3338] 09/28/97 16:13 readdir [1 97/9/28 16:13:17 kant 0.0+0]
/var/clients/kant/var/spool/cron/atjobs
nfsd[3338] 09/28/97 16:13 result: 0
nfsd[3338] 09/28/97 16:13 lookup [1 97/9/28 16:13:17 kant 0.0+0]
fh:/var/clients/kant/var/spool/cron/atjobs n:..
nfsd[3338] 09/28/97 16:13 new_fh = /var/clients/kant/var/spool/cron
nfsd[3338] 09/28/97 16:13 result: 0
nfsd[3338] 09/28/97 16:13 lookup [1 97/9/28 16:13:17 kant 0.0+0]
fh:/var/clients/kant/var/spool/cron/atjobs n:.SEQ
nfsd[3338] 09/28/97 16:13 new_fh =
/var/clients/kant/var/spool/cron/atjobs/.SEQ
nfsd[3338] 09/28/97 16:13 result: 0
[...]
> But really, ls doens't do much else than just lstat (ok, not stat but lstat):
>
> # strace root/file
> [...]
> brk(0x8058000) = 0x8058000
> lstat("tmp/root/file", 0x8054d04) = -1 EACCES (Permission denied)
> write(2, "ls: ", 4ls: ) = 4
> write(2, "tmp/root/file", 13tmp/root/file) = 13
> [...]
Part of log from "strace ls -la /var/spool/cron/atjobs/ >/var/tmp/ls.log
2>&1" as root on the client:
[...]
brk(0x8058000) = 0x8058000
lstat("/var/spool/cron/atjobs/", {st_mode=S_IFDIR|0700, st_size=1024, ...}) = 0
stat("/var/spool/cron/atjobs/", {st_mode=S_IFDIR|0700, st_size=1024, ...}) = 0
open("/var/spool/cron/atjobs/", O_RDONLY) = 3
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
brk(0x805b000) = 0x805b000
getdents(3, /* 8 entries */, 8192) = 184
lstat("/var/spool/cron/atjobs/.", {st_mode=S_IFDIR|0700, st_size=1024, ...}) = 0
lstat("/var/spool/cron/atjobs/..", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
lstat("/var/spool/cron/atjobs/.SEQ", {st_mode=S_IFREG|0600, st_size=6, ...}) = 0
[...]
> I don't hope changing the "stat" to "lstat" in your programme makes
> any difference (if it does, you're messing up some symlinks somewhere),
> but anyway, I cannot test, as the behaviour I see is at least consistent
> (lstat (from ls) and stat from your stat programme both returning error):
>
> # ./test/st
> stat("/boot/no/a" successful.
> stat("/home/joostje/root/file" unsuccessful.
No difference:
kant:/var/tmp> ./st
stat("/boot/no/a" successful.
lstat("/boot/no/a" successful.
stat("/var/spool/cron/.SEQ" unsuccessful.
lstat("/var/spool/cron/.SEQ" unsuccessful.
I'll gladly (well, not gladly exactly, more like if it's necessary then it's
necessary) supply you with a complete dump of configuration files and such
but then I prefer we do it off away from the list.
I'll post a summary to the list what we conclude, when we know what's
happening.
Thanks a lot,
MartinS
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
