David Wolfskill wrote:
> My experience with SU+J is limited (and negative -- in large part,
> because I tend heavily on "dump | restore" pipelines to copy file
> systems, some of which are "live" at the time (danger mitigated by -L
> flag for dump).
As an aside, mine has been pretty positive, except for once having
/ moved entirely to /lost+found and encoded as inode numbers. That
might be enough for some.
> If you can take that system down, I suggest:
>
> * Reboot to single-user mode.
>
> * Disable SU journaling ("tunefs -j disable $special")
>
> * fsck -p / (at least; possibly elide the "-p")
>
> * If you want SU+J, re-enable it ("tunefs -j enable $special")
>
> * While theory says "exit" at this point should just continue the
> transition to multi-user mode, I'd be inclined to just reboot & watch it
> to make sure nothing "weird" happens that you don't know about.
>
> * Re-test.
So, a couple of fscks found some problems, but none causing this.
I found the actual problem. The mount point for /usr was mode 700
even though the root of the mounted filesystem on /usr was mode 755.
Did I explain that clearly (quite difficult because two things are
the same thing, although they're apparently not)?
Seems that for some reason, some but not all actions involving the
transition between . and .. on the mount point use either the
permissions of the mount point or the permissions of the directory
mounted on that mount point. In the past, the permissions in the
mounted filesystem have always trumped the mount point, but I have
no idea what the spec says. Is this a bug?
Ian
--
Ian Freislich
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
