| Summary: | mount attempt returning -EACCES before touching fs-specific code | |||
|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Erik Logtenberg <erik> | |
| Component: | cifs-utils | Assignee: | Jeff Layton <jlayton> | |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
| Severity: | high | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 14 | CC: | gansalmon, itamar, jlayton, jonathan, kernel-maint, madhu.chinakonda, ssorce, steved | |
| Target Milestone: | --- | |||
| Target Release: | --- | |||
| Hardware: | x86_64 | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | cifs-utils-4.8.1-4.fc14 | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 676439 (view as bug list) | Environment: | ||
| Last Closed: | 2011-02-18 01:50:54 UTC | Type: | --- | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Bug Depends On: | ||||
| Bug Blocks: | 676439 | |||
|
Description
Erik Logtenberg
2011-02-07 16:54:27 UTC
Most likely the authentication to the server is failing for some reason. Windows doesn't necessarily log anything on an auth failure. What would probably be a good first step is to turn up debugging and capture a log of the mount attempt. See the instructions here: http://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Enabling_Debugging Err.. well thanks for that wiki page, I'll try those troubleshooting hints. However please note that there was no "Windows" involved. Nor was there any network traffic from the client to the server at all. So I don't understand what you mean by those remarks. Ah, enable debug messages by echoing 7 to /proc/fs/cifs/cifsFYI Yes, I already tried that, it was also suggested in the #fedora channel. Unfortunately dmesg remains completely silent. I do: # echo 7 > /proc/fs/cifs/cifsFYI # cat /proc/fs/cifs/cifsFYI 7 # mount -t cifs -o credentials=/etc/mnt/server.cred //server/share /mnt/server/user2 mount error(13): Permission denied Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) # dmesg (no new output) # cat /proc/fs/cifs/cifsFYI 7 (debugging is still enabled) /var/log/* don't pick up any activity either. Not a single line of logfile about the failed mount attempt. Sorry, I misread your description earlier and thought the server was a windows machine... If dmesg showed no info after turning up cifsFYI, then it sounds like something is being denied at a higher level before calling down into cifs. I know that you said that /var/log/* doesn't have anything... Does anything show up in /var/log/audit after a failed attempt? Yes, if you're getting nothing from cFYI then the problem is almost certainly in a different layer. In 2.6.35, the first thing the VFS will do with cifs is call its get_sb routine. The first thing that cifs_get_sb does is this:
cFYI(1, "Devname: %s flags: %d ", dev_name, flags);
...if that message isn't popping up then the mount is likely failing before the VFS ever touches cifs.ko.
Here's something you can try... If you rmmod cifs.ko and then attempt the mount, does cifs.ko get loaded by the kernel? Thanks for helping me further diagnose this problem. /var/log/audit/audit.log only shows a succesful "su" action that I used to become root. The failed mount attempt does not show up. Now I know that SELinux can deny access silently in certain situations, so I also tried temporarily disabling SELinux just to be sure. It didn't help. I unloaded the cifs module and re-tried the mount. The cifs module did not get reloaded (it still failed with the same error message as before). Do you have an idea what this tells us? That means that the problem is (likely) not with cifs. All of the cifs code is contained within the cifs module. If it's not even getting as far as loading it then it sounds like something is failing before any symbols in the cifs code are called. I'll have to look over the code when I get a chance. For now, I'll go ahead and move this to a kernel bug, and alter the title to better describe the problem. Okay thanks, please let me know if you need me to provide any additional information. Can you do this and paste in the output?
# stat /mnt/server/user2
...note that you need execute permissions on a directory in order to be able to mount on it.
Wow.. something unexpected is going on here. As I said earlier, I am issuing the mount command as root. The mount point is owned by the user that's supposed to use the share. Like this: drwx------. 2 user2 users 4096 Feb 6 23:11 /mnt/server/user2 Now being root I assume I have no permission issues by definition. However, inspired by your last remark, I made the mount point world executable: drwx-----x. 2 user2 users 4096 Feb 6 23:11 /mnt/server/user2 This way, the mount succeeds! Please help me out here, am I being a complete noob for not understanding this? Is the root user actually supposed not to be able to issue mount on a directory owned by a regular user without making it world executable first? For what it's worth: # stat user2/ File: `user2/' Size: 4096 Blocks: 8 IO Block: 4096 directory Device: fd03h/64771d Inode: 4194313 Links: 2 Access: (0701/drwx-----x) Uid: ( 1000/ user2) Gid: ( 100/ users) Access: 2011-02-06 23:21:44.333871250 +0100 Modify: 2011-02-06 23:11:00.368925860 +0100 Change: 2011-02-08 18:51:31.001305300 +0100 Additionally, please note that although explicit o+x permissions are apparently required on the mount point, it appears that this requirement does not apply for the parent directories of the mount point. So without having explicit execute permissions on all the directories leading up to the mount point, I can positively mount, as long as the execute permissions on the mount point itself are explicit. Is there a "|| uid == 0" check missing somewhere or is this intended behaviour? No, I think I know what the problem is... mount.cifs drops most capability flags before it performs a mount. One of those is CAP_DAC_READ_SEARCH, which is what bypasses the permissions check on directories. I think we just need to reinstate that flag before calling mount(2). Setting back to cifs-utils since I understand the problem now, and that's where it is... cifs-utils-4.8.1-4.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/cifs-utils-4.8.1-4.fc14 wow how cool is that :) Jeff, thank you very much for your fast solution! I tested this new version and it works great. Solves the problem. Thanks for testing it and the bug report. If you can vote for the package in bodhi once it's pushed then we should be able to get it into stable updates soon. cifs-utils-4.8.1-4.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update cifs-utils'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/cifs-utils-4.8.1-4.fc14 cifs-utils-4.8.1-4.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. |