Bug 674101

Summary: mount.cifs fails to modify mtab
Product: [Fedora] Fedora Reporter: Jeff Layton <jlayton>
Component: cifs-utilsAssignee: Jeff Layton <jlayton>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: jlayton, kzak, ssorce, steved
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-02-02 09:09:03 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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.