Bug 674101 - mount.cifs fails to modify mtab
mount.cifs fails to modify mtab
Product: Fedora
Classification: Fedora
Component: cifs-utils (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jeff Layton
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2011-01-31 11:23 EST by Jeff Layton
Modified: 2014-06-18 03:40 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-02-02 09:09:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jeff Layton 2011-01-31 11:23:32 EST
Trying to do a cifs mount on recent rawhide and I get a long delay and then this:

# mount  /mnt/salusa
cannot lock mtab

...not too surprising now that /etc/mtab is a symlink to /proc/mounts.
Comment 1 Jeff Layton 2011-01-31 11:26:29 EST
(cc'ing Karel)

I suppose that I need to try to detect when /etc/mtab is a symlink to /proc/mounts and just skip updating the mtab in that case. Is there a suggested way to do this? What about userspace options -- do I need to do something under /dev/.mount? Any hints or thoughts on the right approach for addressing this would be helpful...
Comment 2 Jeff Layton 2011-02-01 07:45:12 EST
After talking with Karel yesterday, I proposed this patch on the linux-cifs mailing list:


...assuming that no-one complains it should go in in a few days. I'll also update the rawhide mount.cifs with the same patch.
Comment 3 Jeff Layton 2011-02-01 13:02:52 EST
Patch committed in cifs-utils-4.8.1-2. Should show up in rawhide in the next day or so. I'll commit the same patch upstream as well in the next day or two providing no one objects.

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