Having changed my desktop OS to Magiea, I find that I can no longer gain access to my NAS box. Previously I had 4 lines in /etc/fstab describing the mounts and they worked fine. With the change of OS though has come this message whenever I try to access the NAS - 'This program is not installed setuid root - "user" CIFS mounts not supported'. I've read up online as much as I can but I'm no further forward in resolving the problem.
Can somebody point me in the right direction please as I need access to the box?
If it helps, the 4 lines in question look like this :- //storage_server/Epox_Share /media/Epox_Share cifs user,credentials=/etc/samba/auth.storage_server.Epox,exec 0 0 //storage_server/Laptop_Share /media/Laptop_Share cifs user,credentials=/etc/samba/auth.storage_server.Laptop,exec 0 0 //storage_server/Linux_Share /media/Linux_Share cifs user,credentials=/etc/samba/auth.storage_server.Mandriva,exec 0 0 //storage_server/Media_Share /media/Media_Share cifs user,credentials=/etc/samba/auth.storage_server.xbox,exec 0 0
In case it helps /etc/hosts looks like this :- # generated by drakconnect 127.0.0.1 localhost.localdomain localhost 192.168.1.25 storage_server
If you want to mount these at every boot, the easiest way would be to edit /etc/fstab and change:
user,credentials=...
to
credentials=...
If you want to be able to mount these as a non-root user at some arbitrary time, it's (slightly) more complicated.
On 26 June 2013 19:56, Keith Edmunds kae@midnighthax.com wrote:
If you want to mount these at every boot, the easiest way would be to edit /etc/fstab and change:
user,credentials=...to
credentials=...If you want to be able to mount these as a non-root user at some arbitrary time, it's (slightly) more complicated.
How so?
I thought auto,user would be fine. At least that's my understanding of http://www.tuxfiles.org/linuxhelp/fstab.html
As for the nosuid stuff:
https://help.ubuntu.com/community/Fstab
specifies that defaults for 'user' is 'nosuid'.
I wonder if:
user,auto,suid,exec,credentials=/etc/samba/auth.storage_server.Epox
would make it all work?
Regards, Srdjan
On Wed, 26 Jun 2013 20:36:29 +0100, todorovic.s@googlemail.com said:
How so?
'user' means that a non-privileged user can execute the mount in question. However, that require root privileges, so 'user' will only work if the mount.* in question has the SUID bit set (mount.cifs in this case). At boot time, /etc/fstab is processed by the root user, and thus the SUID bit is unnecessary.
On Wed, 26 Jun 2013 19:56:06 +0100 Keith Edmunds kae@midnighthax.com wrote:
If you want to mount these at every boot, the easiest way would be to edit /etc/fstab and change:
user,credentials=...to
credentials=...If you want to be able to mount these as a non-root user at some arbitrary time, it's (slightly) more complicated.
I've made that change but if I now issue the command 'sudo mount -a' I get this :- This program is not installed setuid root - "user" CIFS mounts not supported. So do I need to reboot for this to take effect or is there something else I need to do?
If I click on the folder view in Dolphon file manager, I get the message that only root can mount that share so that at least has changed.
On Thu, 27 Jun 2013 11:03:00 +0100, cdw_alug@the-walker-household.co.uk said:
I've made that change but if I now issue the command 'sudo mount -a' I get this :- This program is not installed setuid root - "user" CIFS mounts not
What does
grep -i user /etc/fstab
show?
On Thu, 27 Jun 2013 18:32:21 +0100 Keith Edmunds kae@midnighthax.com wrote:
On Thu, 27 Jun 2013 11:03:00 +0100, cdw_alug@the-walker-household.co.uk said:
I've made that change but if I now issue the command 'sudo mount -a' I get this :- This program is not installed setuid root - "user" CIFS mounts not
What does
grep -i user /etc/fstab
show?
Nothing. It just returns to the prompt.
On Thu, 27 Jun 2013 19:05:49 +0100 Chris Walker cdw_alug@the-walker-household.co.uk wrote:
On Thu, 27 Jun 2013 18:32:21 +0100 Keith Edmunds kae@midnighthax.com wrote:
On Thu, 27 Jun 2013 11:03:00 +0100, cdw_alug@the-walker-household.co.uk said:
I've made that change but if I now issue the command 'sudo mount -a' I get this :- This program is not installed setuid root - "user" CIFS mounts not
What does
grep -i user /etc/fstab
show?
Nothing. It just returns to the prompt.
I've been playing with this some more and I find that from a Debian installation running under Virtual Box, that doesn't have any problems with the user connecting to the same shares. I just clicked on 'Connect to Server', entered the IP address, user name 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?
On a possibly un-related note, I had an installation of Mageia running under Virtual Box (I did that before making the change from Mandriva) and I notice that it retains things like the size of the konsole window whereas the full installation doesn't. When I reboot, the konsole window is full screen on opening despite the option 'Save window size and position on exit' being ticked. So is it possible that some of the files don't have the correct permissions set for them? I have no idea how I would check that though. One file yes, lots of files, not a clue!
On 29/06/13 11:43, Chris Walker wrote:
On Thu, 27 Jun 2013 19:05:49 +0100 Chris Walker cdw_alug@the-walker-household.co.uk wrote:
On Thu, 27 Jun 2013 18:32:21 +0100 Keith Edmunds kae@midnighthax.com wrote:
On Thu, 27 Jun 2013 11:03:00 +0100, cdw_alug@the-walker-household.co.uk said:
I've made that change but if I now issue the command 'sudo mount -a' I get this :- This program is not installed setuid root - "user" CIFS mounts not
What does
grep -i user /etc/fstab
show?
Nothing. It just returns to the prompt.
I've been playing with this some more and I find that from a Debian installation running under Virtual Box, that doesn't have any problems with the user connecting to the same shares. I just clicked on 'Connect to Server', entered the IP address, user name 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?
On a possibly un-related note, I had an installation of Mageia running under Virtual Box (I did that before making the change from Mandriva) and I notice that it retains things like the size of the konsole window whereas the full installation doesn't. When I reboot, the konsole window is full screen on opening despite the option 'Save window size and position on exit' being ticked. So is it possible that some of the files don't have the correct permissions set for them? I have no idea how I would check that though. One file yes, lots of files, not a clue!
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.
My settings for mounting are like this: //SharePath /MountPoint cifs _netdev,auto,credentials=/PathToCredentials,username=AUserName,uid=AUserName 0 0
Note: 1) 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.
2) 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.
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).
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.cifs //sharename /mountpoint/ -o user=AUserName --verbose #Should connect OK
umount //sharename
mount.cifs //sharename /mountpoint -o credentials=PathToYourCredentialsFile --verbose #should connect OK
umount //sharename
mount -t cifs -o credentials=PathToYourCredentialsFile //sharename /mountpoint --verbose #should connect OK
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?
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.
Hope that helps. Steve
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?
On 01/07/13 12:05, Chris Walker wrote:
On Sun, 30 Jun 2013 23:51:41 +0100 steve-ALUG@hst.me.uk wrote:
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
OK. That's pretty fundamentally wrong then!
I googled mount error(5): Input/output error and have come up with 2 possibilities 1) one thread mentioned that adding nounix made their mounting work.
Try as root:
mount.cifs //storage_server/Epox_Share /media/Epox_Share/ -o nounix,user=Epox --verbose
2) I wonder if your machine is in the right samba domain? If it's not then perhaps conencting to the share won't work. On my machine, the domain is listed in /etc/resolv.conf as
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.1.1 search MY_SAMBA_DOMAIN_NAME
I don't know if this is where it's set on your version of linux, nor how to set it.
Other thoughts: 3) Is there a firewall enabled? Could that be causing problems?
4) the user you're using (chris), it has been set up with a permission to use the NAS hasn't it, and you are using the right password?
5) presumably you have all the relevant cifs and samba or smb packages installed?
6) try these commands on your virtual machine and see if they work. If they don't it may be your installation that's in 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.
That's to be expected. Tab completion works with whole file names. It doesn't understand credentials= so pressing tab after you've entered credentials=\et, it will think it's not a file name. Leaving a space and entering \et[tab] it will think it's a file name and complete it for you, but then mount doesn't expect a space between credentials= and the filename, so it will error.
[snip other stuff, not much point looking at the other stuff if the first bit isn't working!]
This thread gave me some ideas https://forums.mageia.org/en/viewtopic.php?f=8&t=5263
Perhaps you should/could ask for help in the mageia forums?
from that thread, try (as normal user) smbclient -L storage_server
and see if it lists the shares and domain name you expect.
Try smbclient \\storage_server\Laptop_Share -U=chris
You have to double up the 's!
Hopefully should connect and give you something like Domain=[YourDomain] OS=[Unix] Server=[Samba x.y.z] smb: >
If so, you can type ls and see if there's a list of files.
Does DMESG show anything when drive mounting goes wrong?
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*
When you get it mounting, you should probably change those file permissions, unless you don't care about people reading the username and password in there.
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?
The short answer to this is I don't know - sorry. You could try the mounting stuff inside your vbox and see if they work. If they don't then there may be a problem with your full installation.
Hope that helps.
Cheers Steve
On Mon, 01 Jul 2013 15:38:58 +0100 steve-ALUG@hst.me.uk wrote:
The short answer to this is I don't know - sorry. You could try the mounting stuff inside your vbox and see if they work. If they don't then there may be a problem with your full installation.
I have now reinstalled Mageia for the second time (twice because I screwed up fstab and it wouldn't boot and it took me a little while to work out what I'd done) but it all now works. The windows are now the size they were before I powered off and new windows don't open up in full screen. So apart from odd things like not having a desktop icon for Sylpheed, it all works.
Thanks to Steve among others for the help.
Sorry late to the party.
You have to be very careful with setuid.
For example if you setuid mount.cifs to root then what is stopping anyone with access to that machine from doing something nasty and unsporting like overmounting /root/.ssh with a copy containing their own keys ?
Or is mount.cifs clever enough to determine you aren't really root and not overmount like that ?
Honestly one of the first things I do when trying to secure a box (and almost certainly one of the first things I'd try if I was looking to get root on a box when I shouldn't have it) is run
find / -perm -4000 -print
and see if anything interesting pops up.
On Mon, 1 Jul 2013 12:05:58 +0100 Chris Walker cdw_alug@the-walker-household.co.uk wrote:
[mega snip]
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.
I've fixed it!
The answer lies in adding sec=ntlm to the fstab lines for the NAS box.
The problem arises because I'm using a kernel of 3.8.3 apparently. If I was using one of 3.8.2 it would be ok. So this may crop up for other people when they update their systems.
All I have to do now is find out why none of the user settings appear to be saved on exit but I have a virtual machine on which to practice as I did with this problem. But first things first, I'm off to watch the Tour de France on tv. I have to get my priorities right :-)
Thanks to all that helped.
On Wed, 03 Jul 2013 17:42:41 +0100 steve-ALUG@hst.me.uk wrote:
On 03/07/13 13:54, Chris Walker wrote:
I've fixed it!
WOOT!
Yes, I'm pleased too :-)
I did get the numbers wrong on the kernel versions though - that's what you get from relying on a poor memory. This link explains it better - http://aptosid.com/index.php?name=PNphpBB2&file=viewtopic&t=2566
I see that my machine is using 3.8.13 and not 3.8.3 as I said earlier.
-
Chris Walker -
Keith Edmunds -
Srdjan Todorovic -
steve-ALUG＠hst.me.uk -
Wayne Stallwood