On Sun, 30 Jun 2013 23:51:41 +0100 steve-ALUG@hst.me.uk wrote:
and password and it worked. So trying again here on Mageia, I entered the following under Dolphin smb://Epox@storage_server/Epox_Share/ and again, after entering the userid and password, I can connect. So why is it that cifs makes me jump through these hoops?
[snip]
Firstly, when you use mount with type (-t) cifs, or mount via fstab with type cifs, the system uses program mount.cifs to do the mounting.
I think the problem is related to this thread: http://forums.fedoraforum.org/showthread.php?s=e91c6903c6d2def717b9b16e5d72c...
which points to this http://www.samba.org/samba/security/CVE-2009-2948.html
Which says, to paraphrase,
if you set the suid bit on mount.cifs, then, you will be able to run mount.cifs as if you were root, without having to use sudo or similar to prove you have permission to do so.
This is a security issue because it allows you to pass it a credentials file along with the verbose flag, and it will output some of the credentials file that the user may not have permission to see.
To prevent this, they've made sure that mount.cifs is not set with the suid flag by default in the default cifs/samba package, and on some installations at least, it will refuse to run if the suid flag is set on mount.cifs. Some people have had success in setting the suid flag, whereas others have recompiled mount.cifs disabling this feature.
The reason you've got this to work under the file manager may be because it is using something else to mount with, perhaps smb rather than cifs. cifs is the successor to smb (for mounting, from/on Linux) so IMO you should use it.
It was using smb - I left the example in above.
My settings for mounting are like this: //SharePath /MountPoint cifs _netdev,auto,credentials=/PathToCredentials,username=AUserName,uid=AUserName 0 0
I have now modified my copy of /etc/fstab to look like this :- //storage_server/Epox_Share /media/Epox_Share cifs _netdev,auto,credentials=/etc/samba/auth.storage_server.Epox,username=Epox,dir_mode=0775,uid=chris,gid=chris 0 0 //storage_server/Laptop_Share /media/Laptop_Share cifs _netdev,auto,credentials=/etc/samba/auth.storage_server.Laptop,username=Laptop,dir_mode=0775,username=chris,uid=chris,gid=chris 0 0 //storage_server/Linux_Share /media/Linux_Share cifs _netdev,auto,credentials=/etc/samba/auth.storage_server.Mandriva,username=Mandriva,dir_mode=0775,username=chris,uid=chris,gid=chris 0 0 //storage_server/Media_Share /media/Media_Share cifs _netdev,auto,credentials=/etc/samba/auth.storage_server.xbox,dir_mode=0775,username=xbox,uid=chris,gid=chris 0 0
Note:
- I specify username and uid to be AUserName, e.g. tom, dick or
harry, the same value for both. This is probably overkill, as one or the other would/should do, but also, the username is specified in my credentials file.
For each of the lines in fstab, the same username is used in the /etc/samba credentials file.
- user in fstab has a specific meaning, meaning an unprivileged user
can mount this drive. Does this conflict with mount.cifs which I think can use the user flag to mean username?
I don't set fstab's "user" flag, so user's can't mount it, unless they use sudo mount -a _netdev I was told apparently indicates it's a network device & so won't be mounted until the network is up.
The permissions for both my mount and mount.cifs on Lububtu (a flavour of Ububtu) are -rwsr-xr-x 1 root root, so they've both got setuid bit set.
File permissions are as follows here :- -rwsr-xr-x 1 root root 41648 Apr 25 18:36 /bin/mount* -rwsrwxrwx 1 root root 40984 Apr 1 13:27 /sbin/mount.cifs*
Where to go from here? Firstly, do you need a user to mount these shares? I suspect not as they're in your fstab, so make sure user isn't in fstab (I think you have already).
I want the shares to be mounted at boot time and I want the files on all 4 shares to be editable/saveable by myself as I'm the only user.
2nd. Become root, using su or sudo -i (depending on your version of linux). experiment with mount.cifs and see if you can mount the shares.
e.g., in Lubuntu sudo -i
mount.cifs //sharename /mountpoint/ --verbose #This should error with Permission denied if you've disabled root as a login name on your NAS
mount error(5): Input/output error
mount.cifs //sharename /mountpoint/ -o user=AUserName --verbose #Should connect OK
As root by using su, mount.cifs //storage_server/Epox_Share /media/Epox_Share/ -o user=Epox --verbose
When I enter the Epox password I get this :- mount.cifs kernel mount options: ip=192.168.1.25,unc=\storage_server\Epox_Share,user=Epox,pass=******** mount error(5): Input/output error
umount //sharename
mount.cifs //sharename /mountpoint -o credentials=PathToYourCredentialsFile --verbose #should connect OK
If I enter the above, when I type in credentials=/et and press tab for the system to complete /etc, it doesn't. If I leave a space it does but then it complains about a bad credentials file.
umount //sharename
mount -t cifs -o credentials=PathToYourCredentialsFile //sharename /mountpoint --verbose #should connect OK
Again, if I leave a space between ...tials and /etc it complains and if I remove the space I get the usual error of :- mount.cifs kernel mount options: ip=192.168.1.25,unc=\storage_server\Epox_Share,user=Epox,pass=******** mount error(5): Input/output error
umount //sharename
Assuming all that's OK. Edit your FStab. Comment out all your NAS shares. Add a new one.
//storage_server/Epox_Share /media/Epox_Share cifs _netdev,auto,credentials=/etc/samba/auth.storage_server.Epox 0 0 Check your credentials file have the filename and path you've just specified, and contains username=AUSERNAME password=SOMEPASSWORD
where AUSERNAME and SOMEPASSWORD are appropriate for an authorised NAS user.
Save it. While still root, try
mount -a
Does it work?
Nope. Usual error.
Try some of the above whilst not root. If it fails, try setting the SUID bit.
If you get it working, check that the file permissions on your credentials file are very restrictive - mine are -rw------- 1 root root so only root can read and write it, that's it.
Here, they're as follows :- ls -la /etc/samba/auth* -rwxrwxrwx 1 root root 32 Jun 25 12:06 /etc/samba/auth.storage_server.Epox* -rwxrwxrwx 1 root root 33 Jun 25 12:06 /etc/samba/auth.storage_server.Laptop* -rwxrwxrwx 1 root root 36 Jun 25 12:06 /etc/samba/auth.storage_server.Mandriva* -rwxrwxrwx 1 root root 29 Jun 25 12:06 /etc/samba/auth.storage_server.xbox*
Hope that helps.
Well, if by help, you mean can I mount the shares, then no. But if you mean have I learnt anything, then yes, a little. I'll persevere and hope I can make some headway.
In a 'clutching at straws' sort of way, do I have to be in any particular groups to do any of this? Bear in mind that this is a new installation and another of the problems I have is that all the windows open at maximum size despite having the flags ticked to save position and size - konsole for example. So I wondered if there's something else going on which is having an effect outside all my efforts. To try and identify if something is amiss, I created a Mageia installation inside VirtualBox. That doesn't exhibit the same issue of window sizes. Would it help for me to compare permissions from the virtual machine to this one on things like the files mentioned above? The VBox installation is also 64bit so I'm assuming I could copy stuff over without issue should I need to. Is that a fair assumption?