I have an NFS client mounting a share set up via YaST (in openSUSE 13.1 x80_64). I have put “users” into the options so I could mount the share from GUI with a regular user. However, whenever I try to mount it from Dolphin, I get an error:
mount.nfs: not installed setuid - “user” NFS mounts not supported.
This seems to be new, since I don’t recall ever having this issue in 12.3. Does anyone else have this issue? Any ideas on how to allow regular users to mount NFS shares again?
For the record, this is the fstab entry in question:
user
Allow an ordinary user to mount the filesystem. The name of the mounting user is written to mtab so that he can unmount the filesystem again. This option implies the options noexec, nosuid, and nodev (unless overridden by subsequent options, as in the option line user,exec,dev,suid).
users
Allow every user to mount and unmount the filesystem. This option implies the options noexec, nosuid, and nodev (unless overridden by subsequent options, as in the option line users,exec,dev,suid).
I’m pretty sure I haven’t changed anything in that regard… So why is it not set to suid? There must be a reason why it’s like that now? Since suid is related to security, I don’t want to mess around with it unless I really have to…
> Well, man mount states:
>> user Allow an ordinary user to mount the filesystem. The name of the
>> mounting user is written to mtab so that he can unmount the filesystem
>> again. This option implies the options noexec, nosuid, and nodev
>> (unless overridden by subsequent options, as in the option line
>> user,exec,dev,suid).
>> users Allow every user to mount and unmount the filesystem. This option
>> implies the options noexec, nosuid, and nodev (unless overridden by
>> subsequent options, as in the option line users,exec,dev,suid).
>>
> Thus imho the OP has a point here.
Not sure I follow.
If mount.nfs isn’t setuid, then user mounts won’t work. My installation
was already set up that way, though.
The fstab options don’t have anything to do with whether mount.nfs is
setuid or not, though.
On Thu, 03 Apr 2014 18:36:01 +0000, GreatEmerald wrote:
> hendersj;2634795 Wrote:
>> I do note that my mount.nfs is flagged SUID as well, so if anything,
>> doing that should resolve the message.
>
> Mine’s doesn’t seem to be:
>
> Code:
> --------------------
> > ls -l /sbin/mount.nfs*
> -rwxr-xr-x 1 root root 110760 2014-02-04 12:50 /sbin/mount.nfs
> lrwxrwxrwx 1 root root 9 2014-02-14 15:50 /sbin/mount.nfs4 →
> mount.nfs
> --------------------
>
>
> I’m pretty sure I haven’t changed anything in that regard… So why is
> it not set to suid? There must be a reason why it’s like that now? Since
> suid is related to security, I don’t want to mess around with it unless
> I really have to…
No idea why it isn’t, but on my system it is, and it’s necessary to do
what you want, so you should set it if you want users to be able to mount
NFS filesystems.
It seems that we do a fair amount of cross posting here.
My citations from the man page were because I read from your post tthat users might be wrong were user is OK. And thy are no synonyms. The one allows only the user that mounted to do an umount. The other lets all users umount irrespective of who mounted.
Of course the original problem is the missing SUID bit. Easy to change, But that is only a symptom. What is the root cause?
> I have:
>
> Code:
> --------------------
> boven:~ # ls -l $(which mount.nfs)
> -rwsr-xr-x 1 root root 110760 Feb 4 11:50 /sbin/mount.nfs boven:~ #
> --------------------
>
> I do not know why you have different.
> You could of course change, but then there a re a few questions, like
>
> - why did this happen in the first place?
> - how many more are there at fault?
Probably would be good to run an RPM verification to see what’s changed
on the system. I just checked nfs-client on mine, and the +s bit is part
of the RPM on 13.1, so it is definitely curious as to why it was
different on OP’s system.
> It seems that we do a fair amount of cross posting here.
It does.
> My citations from the man page were because I read from your post tthat
> users might be wrong were user is OK. And thy are no synonyms. The one
> allows only the user that mounted to do an umount. The other lets all
> users umount irrespective of who mounted.
Ah, I see. Thanks for the clarification. I’ve only ever used “user”,
but my systems are all single-user systems, so I wouldn’t have noticed
the difference.
> Of course the original problem is the missing SUID bit. Easy to change,
> But that is only a symptom. What is the root cause?
On 2014-04-03 18:24, Jim Henderson wrote:
> On Thu, 03 Apr 2014 16:16:01 +0000, GreatEmerald wrote:
>
>> According to man mount, it shouldn’t make a difference… But I’ll try
>> that.
>
> Good to know, I’ve always used ‘user’, so wasn’t aware it was treated as
> a synonym.
And they are not.
The man page says: “For more details, see fstab(5). Only the user
that mounted a filesystem can unmount it again. If any user should be
able to unmount, then use users instead of user in the fstab line.”
The difference: “user” allows a user to mount. “users” allows any other
user to umount. It does not allow a user to mount.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On 2014-04-03 21:06, hcvv wrote:
> Of course the original problem is the missing SUID bit. Easy to change,
> But that is only a symptom. What is the root cause?
Is security set to “normal” or “secure”?
It is set somewhere in yast, I don’t remember the exact place.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
So suid is supposed to be set? Huh. I’ll check another openSUSE 13.1 system I have to see if it’s different or the same there. I’ll also look at snapper to see if it reports any permission changes on my system. Also it may be noteworthy that this system is here since the RC version of 13.1, not an entirely clean install.
No, the difference is that “users” lets everyone umount, “user” lets just the person who mounted to umount. Both “users” and “user” allow mounting freely.
It’s “easy” for me, if you mean this:
> cat /etc/sysconfig/security | head -n 10
## Path: System/Security/Permissions
## Description: Configuration of permissions on the system
## Type: string
## Default: "easy local"
#
# Permission settings to use. By default 'easy', 'secure' and
# 'paranoid' exist. You may define your own though.
#
PERMISSION_SECURITY="easy local"
This applies the permissions settings to your system.
It should have been run during the update anyway, it is called on installation/upgrade of the “permissions” package f.e.
If you get errors, please post them. This would explain why your permissions are wrong in the first place.
