mount.cifs: permission denied: no match for /home/myuser/mydir/myshare found in /etc/fstab

Bug #657900 reported by Hugo Ferreira on 2010-10-10
This bug affects 45 people
Affects Status Importance Assigned to Milestone
cifs-utils (Ubuntu)

Bug Description

Just upgraded from 10.04 to 10.10 and mount.cifs not working anymore as normal user.
If I do 'sudo', I can mount cifs share, otherwise not.
I also can not find umount.cifs after upgrade.


Ian Beardslee (ibeardslee) wrote :

I've noticed this as well.

smbmount //server/share /home/$user/mountpoint -o uid=$user,gid=users,user,credentials=/home/$user/.samba_credentials,dir_mode=0775,filemode=0775,nounix

fails with the error mentioned.

And it's counterpart ..

smbumount /home/$user/mountpoint

fails with "No command 'smbumount' found"

This was working with Lucid, although I did have to

sudo chmod u+s `which mount.cifs`
sudo chmod u+s `which umount.cifs`

To get it working in Lucid.

Ian Beardslee (ibeardslee) wrote :

Hugo, in regard to not being able to find umount.cifs .. a bit more reading ..

EAB (adair-boder) wrote :

I just upgraded as well from 10.04 to 10.10 on 2 out of my 3 systems. The 1 system that I did not upgrade is the one that shares my MF printer/scanner and hard drives to the local network and it's running the fully up-to-date 10.04.1.

Since upgrading the other machines they can no longer access the shared files and folders from the Lucid system, but they can access each other' shares just fine. Even though from the 10.10 systems I can see the shared folders in Nautilus and with smbtree, I cannot mount them.

I tried,

smbmount smb://zeth-zonbu/video /mnt/Zonbu-Videos -o rw

but got this message:

mount.cifs: permission denied: no match for /mnt/Zonbu-Videos found in /etc/fstab

and if I try the above command with 'sudo' this is what I get:

Mounting cifs URL not implemented yet. Attempt to mount smb://zeth-zonbu/video

Ryan Libby (rlibby) wrote :

I also encountered this on upgrade from 10.04 to 10.10, and had previously used the setuid workaround mentioned by Ian Beardslee for 10.04.

For me, mounting as root is not satisfactory. It seems to me that forcing mount as root breaks Kerberos authentication (-o sec=krb5, which used to work), which in turn breaks single-sign-on for CIFS mounts.

Is it a bigger security risk to allow users to run mount.cifs with setuid or to force users to store their passwords on the disk?

KasimirK (berlin) wrote :

Same here - it used to work with setuid-bits on mount.cifs before the upgrade, after the upgrade i get permission denied errors.

Steps to reproduce:
As a normal user, type:
> sudo chmod +s /sbin/mount.cifs
> mount.cifs //server/share ~/directory
does not work, but
> sudo mount.cifs //server/share ~/directory

Changed in ubuntu:
status: New → Confirmed
Raphael Camus (raphael-camus) wrote :

Same for me. All these changes made to mount.cifs behavior over the distro upgrades are starting to be very annoying. I understand that this is for security reasons, but if a root user wants to allow a non-user to do something, it should not be rejected, only warned !!! If the system decisions overcome root user's ones, then what's the use of being root ??
Sory for being rude, I just need a simple way of mounting a share for a non-root user. I found the solution with mount.cifs, then we had to use "sudo chmod +s /sbin/mount.cifs" to allow a non-user (though we had to run the command after each samba update), and now it seems to be simply not possible anymore !! How can we retrieve the old behavior ? Is there a workaround ?
I am a bit upset actually but I ensure that I admire all the people working on the open source community. Thanks again for the hard work.

It would be nice to have a fix. For personal use it is not a major issue. But at enterprise level this should not happen.

fluxgate (chhnews) wrote :

Hi guys,
had the same problem as described above. Solved it by using this lines in /etc/fstab:

//<IP-ADRESS>/<folder_on share> <your_local_mountpoint cifs defaults,iocharset=utf8,codepage=cp850,uid=1000,gid=1000,noauto,user,credentials=~/.smbcredentials 0 0

jahst (christopherbowhuis) wrote :

If you want normal user to be able to mount network share such as samba/cifs or nfs...
you can add the following to the very end of /etc/sudoers file and restart.

# allow members of CDROM group to mount without prompting for root password
%cdrom ALL = NOPASSWD:NOEXEC: /bin/mount, /bin/umount, /sbin/mount.cifs, /sbin/mount.nfs

then add "sudo mount" etc etc to the users mount script.

example of samba mount

sudo mount.cifs //NetworkDrive/"Folder" "MountPoint" -o ip=NetworkServerIPaddress,username="$UN",password="$PW",nounix,noserverino,file_mode=0777,dir_mode=0777

It will NOT ask them for the root password, as the sudoers file stops them from needing it.

this works great for me..
The way I see it, if they have cdrom permissions and are sitting at my PC..
I trust them enough to mount a network share.

Please advise if it's a gaping hole in my security.

Malte S. Stretz (mss) on 2011-02-03
affects: ubuntu → cifs-utils (Ubuntu)
tags: added: maverick
Malte S. Stretz (mss) wrote :

Seems like this feature was removed from cifs-utils, see <> and /usr/share/doc/cifs-utils/NEWS.Debian.gz:

cifs-utils (2:4.0-1) unstable; urgency=low

  * As of this version, the mount.cifs binary is no longer setuid due to
    upstream concerns about the audit status of this code. As a consequence,
    users will no longer be able to run mount.cifs directly to mount shares
    unless mount points have been individually configured in /etc/fstab with
    the "user" mount option.

    Sites that require their users to retain the ability to mount arbitrary
    CIFS shares without system-level configuration may want to consider using
    the fusesmb package instead.

 -- Steve Langasek <email address hidden> Sun, 28 Feb 2010 16:07:14 -0800

Steve Cunningham (icl) wrote :

For now since this thing is useless on Ubuntu Maverick, can someone please post the solution to return the sudoes file so that you can sudo

Currently any sudo is now broken and I can't run any programs via sudo at all.

Steve Cunningham (icl) wrote :

well for now I restored the sudoers to operate normally by selecting recovery mode when the system is booting up

Then visudo command

And comment out the lines which Smb4k has added for some reason

# /etc/sudoers
# This file MUST be edited with the 'visudo' command as root.
# See the man page for details on how to write a sudoers file.

Defaults env_reset

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root ALL=(ALL) ALL

# Allow members of group sudo to execute any command
# (Note that later entries override this, so you might need to move
# it further down)
#%sudo ALL=(ALL) ALL

#includedir /etc/sudoers.d

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

# Entries for Smb4K users.
# Generated by Smb4K. Please do not modify!
#User_Alias SMB4KUSERS = agent86
#Defaults:SMB4KUSERS env_keep += "PASSWD USER"
#SMB4KUSERS agent86-S2865 = NOPASSWD: /usr/bin/smb4k_kill
#SMB4KUSERS agent86-S2865 = NOPASSWD: /usr/bin/smb4k_umount
#SMB4KUSERS agent86-S2865 = NOPASSWD: /usr/bin/smb4k_mount
# End of Smb4K user entries.

All entries are commented out and the only thing that is not commented are these:

Defaults env_reset
root ALL=(ALL) ALL
%admin ALL=(ALL) ALL

note that smb4k also had changed this line to read:
%sudo ALL=(ALL) ALL

which I'm not sure if it should be commented or not so I commented this out until i can figure out how to edit these smb4k lines so that I can actually use the program

Anyhow this won't solve your smb4k troubles but at least will restore you ability to use sudo
I hope this helps

Malte S. Stretz (mss) wrote :

From reading the Changelog, it seems like smb4k 0.10.65 (1.0.0 alpha1) supports KAuth to raise the permissions. You should file a bug against smb4k to have the newer version packaged.

Zakalwe (elethiomel) wrote :

This completely breaks libpam-mount for me with CIFS

libpam-mount mounts the user's home directory via CIFS from a server when the login. As we have thousands of users, it's silly to have them all in the fstab. It used to work perfectly in Karmic.

Using sudo is not really an option for us either.

Malte S. Stretz (mss) wrote :

I don't use libpam-mount but 'man 5 pam_mount.conf' tells me that it can call mount.cifs as root (ie. implicit sudo), even defaults to this. You don't need to have your mount points in /etc/fstab if you are root, so you should be fine. If libpam-mount is indeed broken by this change, you should file a bug against libpam-mount.

nh2 (nh2) wrote :

We should do something about this. Currently, it is impossible to let users mount Windows shares without giving them some kind of extra privileges (the setuid root in 10.04 was not nice, either). Gnome's "Connect to server" (gvfs) works, but is gnome-specific and not easily scriptable.

@jahst: Thanks for your workaround, it works well.

Ed Harcourt (edharcourt) wrote :

No final resolution on this? This is maddening.

Ed Harcourt (edharcourt) wrote :

I have the same problem with comp sci labs that use pam and mount using cifs, these keep me from migrating to the next LTS from 10.04. Same issues as #14.

tags: added: precise

I'm using 12.04.

I can auto mount windows shares via fstab, and I have user-level scripts that consume these shares successfully.

However, sometimes a window server is rebooted. When this happens, the auto mounting that occurred via fstab happened before the windows reboot and is therefore expired (unmounted).

In my user-level scripts, I need a way to remount so the scripts don't fail.

If I put sudo mount -a, into the script, that won't work because the automated script can't type in a password even if that user is a sudoer.

mount -a (without sudo) also doesn't work because it gives error "only root can do that".

I've added the user flag to these mounts in fstab, but this too still doesn't give the user-script the ability to mount the windows share, you get an error:

no match for /media/windowsShare found in /etc/fstab

Please advise.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.