From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4 Description of problem: using a NIS map or a local autofs map, on a same exports host and between to directory with de same root, if there is 2 differents access rights (read and write) on each mount only the read access work when it was invoked first. i am sorry for my poor english Version-Release number of selected component (if applicable): autofs-5.0.1-0.rc3.29 How reproducible: Always Steps to Reproduce: with a nis map like that (/etc/auto.custom): soft -rw,hard,intr host:/home/soft private -ro,soft,intr host:/home/private if you access first to the private mount point and on a second time to the soft mount point, autofs keep the read access right an we can't write to the soft directory. example: cd /S/private cd /S/soft touch foo touch: cannot touch 'foo': read-only file syste Actual Results: the same map work on others Linux distributions ans on Sun workstations Expected Results: Additional info:
I have tested, Fedora core 6 i386, x86_64 and Fedora core 7 x86_64 with the same wrong results
(In reply to comment #0) > > Description of problem: > using a NIS map or a local autofs map, on a same exports host and between to directory with de same root, if there is 2 differents access rights (read and write) on each mount only the read access work when it was invoked first. > > i am sorry for my poor english What I think you're saying is that multiple mounts for the same NFS exported filesystem always have the same options as the first mounted instance, regardless of the options requested on second and subsequent mounts. Is my understanding correct? Ian
it's exactly that i mean bertrand
the exported filesystem is located on a NAS emc server.
(In reply to comment #3) > it's exactly that i mean That's a known issue with upstream kernel NFS client. People are working to fix it but I'm not sure when or if this will reach FC6. Ian
(In reply to comment #2) > (In reply to comment #0) > > > > Description of problem: > > using a NIS map or a local autofs map, on a same exports host and between to > directory with de same root, if there is 2 differents access rights (read and > write) on each mount only the read access work when it was invoked first. > > > > i am sorry for my poor english > > What I think you're saying is that multiple mounts for the > same NFS exported filesystem always have the same options > as the first mounted instance, regardless of the options > requested on second and subsequent mounts. > > Is my understanding correct? > > Ian > yes it is
(In reply to comment #5) > (In reply to comment #3) > > it's exactly that i mean > > That's a known issue with upstream kernel NFS client. > People are working to fix it but I'm not sure when or > if this will reach FC6. > > Ian > thank's so i am waiting for the next release to correct this bugs Bertrand
(In reply to comment #7) > (In reply to comment #5) > > (In reply to comment #3) > > > it's exactly that i mean > > > > That's a known issue with upstream kernel NFS client. > > People are working to fix it but I'm not sure when or > > if this will reach FC6. > > > > Ian > > > thank's > > so i am waiting for the next release to correct this bugs I'm not sure you understood what I meant. Let me say it again, slightly differntly. This isn't an autofs problem and there's nothing autofs can do to change the behavior. The change has been present in the Linux kernel since early in the 2.6 series and only fairly recently has the number of reports warranted people to work on fixing it. Some believe this is the correct behavior because allowing different mount options on the client for the same filesystem leads to a false sense of security as this can be easily subverted. At least that's something like what I got from the discussions I've seen. If you'd like to request that something be done about this for FC6 then we should change the component of this bug to be "kernel" instead of "autofs". Ian
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers