User mounted drives ?

Is there a setting some where in opensuse that prevents user mounting?

I can mount ok as su and have set user in the mount options but get the message - only root can do this?

On 2011-06-05 14:36, ajohnw wrote:
>
> Is there a setting some where in opensuse that prevents user mounting?
>
> I can mount ok as su and have set user in the mount options but get the
> message - only root can do this?

What do you want, impede a user from mounting, or allow a user to mount
something?

Do you have, perhaps, an entry in fstab to mount something as user but does
not work? Post the entry here.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

It isn’t enough to just add user in the mount options, see this excerpt from the mount (8) page:

user
    Allow an ordinary user to mount the file system. The name of the mounting user is written to mtab so that he can unmount the file system 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 file system. This option implies the options noexec, nosuid, and nodev (unless overridden by subsequent options, as in the option line users,exec,dev,suid). 

Don’t know if you already have but it may be worth you taking a look at the man page yourself as there are other options in there that may affect or be useful for what you’re trying to do

I’m no expert in this area as I’ve never wanted my drives mountable by every user so have always found it simple and convenient to put scripts in my own folder to mount ‘non-permanent’ drives using the sudo -s switch

This allows me to do for example: Alt & F2, type backups, hit Enter and my backups drive is quickly and easily mounted, and as I use nis logins with nfs shares this means I don’t have to go messing with fstabs on every machine, my scripts are available wherever I’m logging in from

May not suit your scenario but it does serve as a reminder that there’s more than one way to skin a cat :wink:

in case you find it handy btw, sudo -s is used like this:

echo “rootpass” | sudo -s [then your commands go here]

I’ve pored over man mount (8) till blue in the face - and mount.cifs too. cifs as it’s a nas. I’m beginning to think that what I am trying to do is impossible. Basically mount when I want to as a specific group user not at boot via fstab. Easy but when I do mount I don’t want to use the root password.

This line fstab may do what I want but still needs root password when I mount -a later


//192.168.1.20/Discs/home/john/Desktop/NAS cifs forceuid=john,forcegid=Nas1,file_mode=0770,dir_mode=0770,user

I say may because having changed uid to dummy/dummy (a nas account that can’t do much). It still needs password for john. I can of course forget fstab and mount directly but this will always need root password.

There are other arrangement eg uid guid produce the same effect… KDE show the rights incorrectly with those. Force - cures that.

Sudo -s would be a solution but leaving my root password kicking about in a shell script.

Basically what I need is an fstab line that prepares the system for later mounting by specific users.

No doubt some will mention samba but this will not allow some applications to use the nas in the way I want. The kde network drive connect doesn’t either. So please forget them.

Have to go back to my 1st question. Taking the fstab line more or less out of man fstab(5) it goes as follows


//192.168.1.20/Volume_1 /home/john/Desktop/NAS cifs rw,owner=john,noauto

I didn’t appreciate that fstab was used in a way that involved mount -a. I have also previously found a bucket of incantations that have exactly the same results as follows.

Later when I use a mount -t etc command to actually mount it I get an “only root can do this” error message. Su password and enter exactly the same thing and I get asked for my user password on the nas and lo the directory on my desktop gets connected to the nas.

If I use a mount.cifs command as a user I get the error message


This program is not installed setuid root -  "user" CIFS mounts not supported.

If I fix that with chmod 4755 I just get permission denied as a user.

So what’s prevent user/owner in fstab from working correctly?


On 2011-06-05 22:36, ajohnw wrote:
>
> Have to go back to my 1st question. Taking the fstab line more or less
> out of man fstab(5) it goes as follows
>
> Code:
> --------------------
>
> //192.168.1.20/Volume_1 /home/john/Desktop/NAS cifs rw,owner=john,noauto
>
> --------------------

Notice that you have two different permission sets involved. One is the
standard mount, for which you forgot to specify the option “user” or
“users” in the line above. The other permission set is for samba/cifs,
which is a totally different issue; you have to configure samba as well, so
that its password is stored or not asked for.

How to configure samba I will leave for somebody else to answer, it is not
my field.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

Hi As I pointed out earlier I do not want to use samba. It’s slow in several areas and it does not allow many applications to work correctly with their files on a nas.

I have seen several methods of setting up samba and have tried them all. The best is probably this one How To Network openSUSE 11.4 And Windows but it still has limitations.

The reason for the problem is that mount/mount.cifs has been crippled and has finish up with the idiotic situation where the root password is needed for a user to enter their nas access password. Given the rising popularity of nas’s this is a rather strange direction to go. Mount.cifs is stand alone and intended to be used in this way. Discless work stations are one aspect of that. Root password security can be obtained with an uncrippled mount.cifs from the 11.2 repo by creating a group with only root and intended users or specific user in it. The same technique can be used with umount.cifs. If a user attempts to mount and isn’t in the group it’s blocked in the same way as the crippled version is.

The samba and kde problems where kwrite can function perfectly normally with files on the nas where as vlc for instance and many other none kde apps can not is probably down to the same crippling.

I should add that mount.cifs doesn’t need a corresponding line in fstab. It can be added but it makes no difference.


You say you don’t want to use samba and you’re trying to setup cifs mounts, but cifs is based on the smb protocol isn’t it? I do know that I’ve seen no end of pages on the net relating to samba/cifs

I don’t think you’ve mentioned whether you have any windows machines on your lan but that’s the scenario which samba and cifs are really meant for, networks with windows machines as members, if there aren’t any windows machines have you considered nfs?

Here I have samba for the windows machines and nfs for the linux ones and the linux machines simply have an entry added in dolphin’s sidebar which mounts the nfs shares

With nfs I have no issues running any files in any app across the network, in fact the entire /home on the clients is an nfs share

Available options for cifs mounts aren’t the same as those for ‘normal’ local mounts, Swerdna’s pages are always worth checking out for this kind of thing, here’s his cifs page: http://opensuse.swerdna.org/susesambacifs.html

If you have a look through that page he shows how to deal with things like credential issues and how to delay fstab entries until the network is up, might well find the answers you need there

When it comes to anything samba related (not to mention various other networking questions) … swerdna is The Man

Not entirely correct. If mount.cifs is used it’s perfectly capable of working on it’s own. It doesn’t need samba. The cifs protocol is wired into the kernel and as such can be used like a native disc format just like ext3 etc. Application do not need to know about it. So called transparent network operation.

The best place to look for mount.cifs doc is samba.org but cifs is basically a kernel function. I have read some where that it was intended to be used with diskless work stations and things like a nas. Samba have adopted the protocol to replace the old smb protocols.

I do not want shares all I want to do is use a nas. The problem I had using samba cifs are exactly the same as using dolphin’s microsoft network drive connect. One of the odd problems with both was that accesses from my desktop used cifs what ever I set. This turned out to be partly due to not activating nfs on the nas but some transfers still used cifs. Once I activated nfs things changed and other problems - to me at least - cropped up. One was server searches taking a long time. One instance of that occurs when kde automount is used. After logging in the desktop slowly fades up and the desktop is usable. The automount resuts in 10+ secs of of dead desktop. The other aspect relates to navigating through a directory structure from within an application over the network. It’s oh so slow. I followed several different methods of setting up samba. The other problems came about when I tried to open or save a file onto the nas. Kwrite fine but gimp,libre office and I suspect many other none k apps just give an error message “You can only select local files”. This is down to kde. It’s possible to find holes in it though. For instance drag an avi off the nas onto a vlc window and nothing happens. Make a vlc desktop icon and drag the file onto that and it plays despite a plasma shell error message - sorry can not find file. There are other holes. VLC by the way does have the correct entries in it’s desktop file that should allow it to play files from the network. As I’m a software engineer I basically got fed up with this approach - looks like india rubber man has been at work to me - sticking plasters all over the place so I moved on to mount.cifs. There are also lots of reports about indicating other problems such as downloading before loading into applications. Some seem to find a cure. One cure made no difference for me. The link I posted indicates several areas that may need changing and if they don’t - more sticking plasters have been applied.

Mount,cifs has been crippled in 11.4 such that if it’s used the root password is needed to allow a user to enter their nas access password. More sticking plasters.

:wink: Sorry if I sound annoyed - I probably am. Waisting this much time on something like this might even drive me back to windoze after at least 10years.

rotfl! Any way it works exactly as I want it too and is ideal for a nas. Access is instantaneous and it completely bypasses the kde problems. It’s also secure with a little thought and could be made totally bomb proof. My needs really boil down to needing to work on certain things from both windoze and kde. The nas is a sort of huge usb stick that doesn’t have to be carried around. Unfortunately my microscope camera can’t be driven from linux. There are also a number of open source packages that aren’t available on linux. There are also windoze machines about here and of course operation there is flawless so why should I suffer alone.

One things for sure. KDE would be better off using mount.cifs to connect to a microsoft network drive and leaving samba for what it’s intended for. Given the points I have mentioned it could be that they will never sort it out. I’m guessing but the depths of kde seem to indicate remote software usage a la google’s ideas and others as then software is rented not bought and never gets installed on a users machine. This may explain the need for the changes to desktop files which currently wont work.