Bug 718464 - NFS exports bind mounts as read-only
Summary: NFS exports bind mounts as read-only
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 15
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-07-03 09:33 UTC by Rolf Fokkens
Modified: 2011-11-10 17:44 UTC (History)
11 users (show)

Fixed In Version: systemd-37-3.fc16
Clone Of:
Environment:
Last Closed: 2011-11-10 17:37:03 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Rolf Fokkens 2011-07-03 09:33:23 UTC
Description of problem: After upgrading to Fedora 15 (both NFS client and server) the client-access to NFS directories suddenly was read-only. Both client (/proc/mounts) and server (/proc/fd/nfsd/exports) claimed that all was rw.

Furhter investigation showed that the bind mounts (like fstab: /home/ /var/exports/home none bind 0 0) used for the NFS4 exports had all become ro. This resulted in denying write access by NFSD as well.

During mount the bind mounts copy rw access from the original filesystem, which in this case is the root filesystem. During the early stages of the boot process the filesystem is mounted ro, to be remounted rw after checking. So my guess is that systemd does these bind mounts in a very early stage.

Bug 710368 may be related.

Version-Release number of selected component (if applicable):
kernel-2.6.38.6-26.rc1.fc15.x86_64
systemd-26-5.fc15.x86_64
nfs-utils-1.2.3-11.fc15.x86_64

How reproducible: 90%, On some accasions the bind mounts are mounted rw. 

Steps to Reproduce:
1. Create bind mounts for existing directories on the root filesystem
2. Reboot
3. Not that the bind mounts are ro unlike the root filesystem
  
Actual results:
EROFS when initiating write access to NFS files/directories

Expected results:
Normal read/write access

Additional info: After boot the bind directories can be remounted rw, which solves the problem

Comment 1 Michal Schmidt 2011-07-04 11:36:52 UTC
I managed to reproduce using this in fstab:
/etc  /dummy  none bind 0 0

The problem is that there is no ordering between dummy.mount and remount-rootfs.service. If dummy.mount wins the race, it creates the bind mount while root is still read-only.

Comment 2 Oron Peled 2011-09-08 06:28:24 UTC
Some more data points:
 * I have several bind mounts for NFS4:
     /home     /nfs4exports/home
     /var/mail /nfs4exports/mail
     ...
   which are obviously exported 'rw' via /etc/exports

 * The 'ro' bind-mount bug is happening on 'mail' but not on 'home':
   - /home is on a separate LVM logical volume
   - /var/mail (and /var) are not (so they belong to /)

 * So it's pretty clear all bind mounts should be 'After' the remounting 'rw' of '/'
   Any way to implement this logic?

 * Another test I did was to try and add in /etc/fstab comment=systemd.automount
   for all bind-mount lines, to try and delay their execution -- this did not
   help at all.

 * As a result after every server boot I need to manually 'exportfs -u' all
   these NFS volumes, umount the /nfs4exports/..., remount them again and
   'exportfs -a' again.

 * Ugly workaround: I moved all my bind-mounts from /etc/fstab to manual commands
   in /etc/rc.local and now everything works. So far for "script-less" boot ;-)

Comment 3 Tom Hughes 2011-10-05 08:07:22 UTC
I'm seeing this as well. A simple test case that I just setup was to create /export/tmp in a VM and add the following to my /etc/fstab:

/tmp  /export/tmp  none  rw,bind  0  0

then I rebooted, and lo and behold that mount is actually read only:

fedora15 [~] % fgrep /export/tmp /proc/mounts
/dev/mapper/vg_fedora15-lv_root /export/tmp ext4 ro,relatime,user_xattr,barrier=1,data=ordered 0 0

fedora15 [~] % touch /export/tmp/foo
touch: cannot touch `/export/tmp/foo': Read-only file system

Incidentally, you don't need to do that whole unexport, unmount, mount, export cycle to fix it - a simple "mount -o remount <filesystem>" is enough.

Comment 4 Fedora Update System 2011-10-11 19:18:01 UTC
systemd-37-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/systemd-37-1.fc16

Comment 5 Rolf Fokkens 2011-10-11 19:50:50 UTC
Updated the package on my F15 system; the problem has gone.

What's the next move? Revert to the systemd-26-10.fc15 packages and wait until they're updated or just leave the F16 packages on my F15 system?

Comment 6 Fedora Update System 2011-10-12 01:32:19 UTC
systemd-26-11.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/systemd-26-11.fc15

Comment 7 Rolf Fokkens 2011-10-12 21:35:30 UTC
Installed the F15 package, this one also works.

Comment 8 Fedora Update System 2011-10-13 00:52:45 UTC
Package systemd-26-11.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-26-11.fc15'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-14203
then log in and leave karma (feedback).

Comment 9 Michal Schmidt 2011-10-13 09:22:22 UTC
(In reply to comment #7)
> Installed the F15 package, this one also works.

Thanks for testing. If you have a FAS account, please add karma to the update in Bodhi.

Comment 10 Fedora Admin XMLRPC Client 2011-10-20 16:30:26 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 11 Fedora Update System 2011-11-10 17:37:03 UTC
systemd-26-13.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 12 Fedora Update System 2011-11-10 17:44:13 UTC
systemd-37-3.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.