I’ve been happily using my nas for a long time and did a yast update yesterday and can’t any more. I’m using 11.4 but I don’t think this relates to versions. To connect to my nas I simply ran this
I could then click on the nas folder icon on my desktop and use it just as if it was on the local disc.
When finished I simply ran this to disconnect from the nas
/sbin/umount.cifs //home/john/Desktop/NAS
In order to get this to work I had to roll back mount.cifs and umount from opensuse 11.3. It took most of my spare time for a month to sort this out. I even had samba up and running but it was terribly slow and also prevented me from doing several things that I wanted to do. I also do not want to run samba. CIFs is supported directly by the kernel for remote discs which exactly how I use my nas. The reason for the roll back was that mount.cifs had been purposefully crippled because certain people had asked if it was secure - not because there was any known security issues with it. I bug reported this and had to open it a couple of times. More on that later.
Basically I avoid going down below the desktop and have no wish to be become proficient there so have no idea what I need to do in order to fix the post update problems. I also can’t afford to take another month playing about until it works again.
Looking in /sbin I have new mount and umount cifs and a mount.cifs.install. Run as above I just get permission denied. If I run it in a console as root the console hangs and times out - eventually. If I run the install from the consol as root it asks for a password and neither the user nas password or the root password achieves anything. Roll back to the mount.cifs I was using and I just get permission denied.
Back to the bug report again. This is why I risked an update. Last entry quote
I verified that it is possible to setuid mount.cifs and use it with updated 11.4 (cifs-utils-4.6 and above). So, please update cifs-utils and setuid mount.cifs (as you need it)
and use it to allow user to mount CIFS shares. I’ll close this bug.
This is why I risked an update also by now 11.4 is likely to be as fixed as it will ever be. Problem is I do not understand
what the above really means. Help
One thing I haven’t checked is that a line I added to fstab is still there but my recollection is that this wasn’t really needed. I added it while trying to get it
On 05/23/2012 07:56 PM, John 82 wrote:
>
> I’ve been happily using my nas for a long time and did a yast update
> yesterday and can’t any more. I’m using 11.4 but I don’t think this
> relates to versions. To connect to my nas I simply ran this
>
>
> Code:
> --------------------
> /sbin/mount.cifs //192.168.10.153/Volume_1 //home/john/Desktop/NAS -o username=john,guid=Nas1
>
> --------------------
>
Three quick questions:
(1) Is “guid” a typo?
(2) On openSUSE, did you create a group named “Nas1”
(3) If the answer to (2) is “yes”, why did you do that?
Don’t ask me where the info came from. I was tearing my hair our for weeks with a lot of internet searches on mount cifs. This is how I discovered that it was crippled.
> In order to get this to work I had to roll back mount.cifs and umount
> from opensuse 11.3. It took most of my spare time for a month to sort
> this out. I even had samba up and running but it was terribly slow and
> also prevented me from doing several things that I wanted to do. I also
> do not want to run samba. CIFs is supported directly by the kernel for
> remote discs which exactly how I use my nas. The reason for the roll
> back was that mount.cifs had been purposefully crippled because certain
> people had asked if it was secure - not because there was any known
> security issues with it. I bug reported this and had to open it a couple
> of times. More on that later.
>
> Basically I avoid going down below the desktop and have no wish to be
> become proficient there so have no idea what I need to do in order to
> fix the post update problems. I also can’t afford to take another month
> playing about until it works again.
I’m confused. I don’t understand what you have done or what is the problem.
Also you speak about a bug report, but this is not a bug report - so no
idea how to help.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
On 2012-05-23 13:06, John 82 wrote:
>
> 1) no - II copy pasted that from the console line
There is no guid option in the manual.
> 2) Yes
With that case? Problematic.
> 3) Don’t ask me where the info came from. I was tearing my hair our for
> weeks with a lot of internet searches on mount cifs. This is how I
> discovered that it was crippled.
You should get used to the command line and the manuals if you want to
accomplish things in Linux.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
On 05/23/2012 09:06 PM, John 82 wrote:
>
> 1) no - II copy pasted that from the console line
> 2) Yes
> 3) Don’t ask me where the info came from. I was tearing my hair our for
> weeks with a lot of internet searches on mount cifs. This is how I
> discovered that it was crippled.
>
> John
>
>
Try this one (all on one line):
On 2012-05-23 14:36, John 82 wrote:
>
> Not fully uderstanding what I am doing I have just changed the advanced
> permissions set UID and set GID in mount.cifs
>
> Now if I enter my usual command line I get
>
> mount.cifs: permission denied: no match for /home/john/Desktop/NAS
> found in /etc/fstab
>
> :’( yet there is,
Prove it!
That is, print here the line in fstab that should match, inside code tags.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
From the command line suggested I get “mount only root can do this”
This is where I came in on this problem initially. Naturally I assumed that I could enter the command into a shell script as root and a user would then be able to use it providing they had the correct nas access password for their nas directory. It turned out that the rights aspect of mount.cifs had been interfered with to prevent it from working. From the last comment on the bug I reported uid etc should now be honored. That’s why I just tried setting uid,guid and sticky on mount.cifs Not that I fully understand these. In the past I have run and maintained both dec and novel netware servers so I do know what is needed. No room left for picking up yet another op system. I only go there when I must. I
Having changed permissions as mentioned in my other post I get a complaint about the directory not being in fstab. . Only problem then is that it is with the rider that I thought that style of use of fstab was depreciated or at least on it’s way out.
I will read the link but remember it well. One of the general problems with many of these information sources is that they are often not up to date.
John
:\ Just notice my spell checker seems to have turned itself off - please excuse any. 20 years of working in assembler seems to have reduced my capabilities in that area. Odd typo’s too.
I just looked at the page Swerdna posted and noticed the words samba which I do not want to run. There were various anomalies when working with files on the nas this way. Some of this may be down to KDE. It was also ponderously slow especially when navigating directories via a mouse from Dolphin.
I was using mount.cifs as outlined here - mount.cifs(8) - Linux man page -note the comment that when used this way it completely bypasses samba.
The kernel supported diskless workstations directly via cifs which is very similar to the way I use my nas. Interestingly there is no man page for mount.cifs.install here. The program itself suggests looking at it’s man entry - there isn’t one. Google doesn’t show one either.
This man entry seems to have changed since I last looked and has been expanded a lot but I am fairly sure my command line came from elsewhere. It took a long time to find, also the reason for the crippling.
Well have tried the suggestions in the kernel org doc. My line in fstab looks to be correct but mount.cifs still says it’s not there. Also tried changing user to user=john but the group should look after that. Basically it does seem to accept my mount.cifs command.
I’m surprised that it works what with the mixture of IP networks, with mounts in fstab working simultaneously with CLI mounts, with mounting from the CLI as a non-root user and with invalid options in the mount commands.I usually find that disorganised and haphazard attempts fail, but good for you, congrats that you got the mount command to work. Linux is indeed full of rewards and surprises.
There is more results for mount cifs problems coming up on google than when I last had the same problem. Many trying to do what I am trying to do one way or the other. It isn’t a disorganized haphazard attempt as at a basic level it follows the kernel org suggestions. Confusion reigns because people seem to assume cifs is in samba’s domain when basically it’s more a case of samba happening to use it. From web posts it seems that there is yet another approach. Cifs direct is much quicker than samba but apparently an even quicker route is to use ntfs. Pass but the kernel also directly supports that but opensuse has been known to miss it out of compiles.
As to mount.cifs.install absolutely nothing other than dev bug reports so what on earth is it doing there. Wouldn’t be too bad maybe if it’s claimed man page actually existed.
I found one “fix”. Some one used number id’s for user and group and loh the often malicious linux demon gave up and allowed him to do what he wanted to do. He also used a slightly different syntax order in fstab. Tried and mount.cifs still can’t find it.
If you wish to see something disorganized and haphazard take a read of this - LinuxCIFS utils - SambaWiki You will also probably find any examples of usage, perish the thought if they even exist on the samba site, are years out of date.
On 05/24/2012 06:26 AM, John 82 wrote:
>
> swerdna;2464667 Wrote:
>> I’m surprised that it works what with the mixture of IP networks, with
>> mounts in fstab working simultaneously with CLI mounts, with mounting
>> from the CLI as a non-root user and with invalid options in the mount
>> commands.I usually find that disorganised and haphazard attempts fail,
>> but good for you, congrats that you got the mount command to work. Linux
>> is indeed full of rewards and surprises.
>
> Well it still isn’t getting my nas to work.
>
> There is more results for mount cifs problems coming up on google than
> when I last had the same problem. Many trying to do what I am trying to
> do one way or the other. It isn’t a disorganized haphazard attempt as at
> a basic level it follows the kernel org suggestions. Confusion reigns
> because people seem to assume cifs is in samba’s domain when basically
> it’s more a case of samba happening to use it. From web posts it seems
> that there is yet another approach. Cifs direct is much quicker than
> samba but apparently an even quicker route is to use ntfs. Pass but the
> kernel also directly supports that but opensuse has been known to miss
> it out of compiles.
>
> As to mount.cifs.install absolutely nothing other than dev bug reports
> so what on earth is it doing there. Wouldn’t be too bad maybe if it’s
> claimed man page actually existed.
>
> I found one “fix”. Some one used number id’s for user and group and loh
> the often malicious linux demon gave up and allowed him to do what he
> wanted to do. He also used a slightly different syntax order in fstab.
> Tried and mount.cifs still can’t find it.
>
> If you wish to see something disorganized and haphazard take a read of
> this - ‘LinuxCIFS utils - SambaWiki’
> (http://wiki.samba.org/index.php/LinuxCIFS_utils) You will also
> probably find any examples of usage, perish the thought if they even
> exist on the samba site, are years out of date.
>
> John
>
>
I suggest that you
(1) take the mount cifs line out of fstab
(2) find out what IP address the NAS has on the LAN (e.g. 192.x.y.z)
(3) Use web browser to address the NAS at that IP address and set it for
guest access
(4) open a terminal window and enter su to get rootly powers
Run the command in the root terminal as follows (all one line):
mount -t cifs //192.x.y.z/Volume_1 //home/john/Desktop/NAS -o
guest,uid=john,gid=users
(of course, you’ll have different integers than 192.x.y.z, as determined
in step 2)
(you have to do those 4 steps in the order given or it won’t work)
I’ve been out all morning. I will try that and it should work as all is set up as su. Not very convienient for me really but if I have to … Guest access may not be much use to me really though as there are other users and directories on the nas. If I allow guest on mine I would need to check that this doesn’t include all comers.
On fstab entry I have just done some checks as to what actually generates the error message. I gave mount.cifs a spelling mistake and it came out in the error message. I changed fstab’s name and also generated a file with the same name. From this unless a root mount bypasses an fstab check the suggestion may still not work. Mount.cifs 1st check that the mount point exists and then checks fstab. Part of the exists check also includes can the user actually make use of it or at least change directory to it.
All of this of course is no problem for windoze users. Frankly I wonder why suse and others do not include an uncrippled version called usermount.cifs that admin’s can delete if they don’t want it. From changes in this area it looks like attempts are being made to make setting it up look like microsoft. Stupid. All that will happen is that cifs will loose out if it wont do what it should do. I strongly suspect the only reason nas’s support cifs is that they run linux to save a lot of money on software dev costs. People do many things with nas’s. Mine will finish up connected to several pc’s, the telly and a strange box that also probably runs linux but recieves telly, records it and also plays discs and not just the pc’s make use of the internet. Trying to run that lot through samba would be a joke - it can all come out on a pc as well - at the moment only if it’s a windoze pc…
Well I have it working - sort of. I decided to follow the advice of the person that closed the bug I reported. I compiled and installed the 4.6 cifs utils as suggested. It does seem to allow the flags to be set to allow a user to run it (others r-x) but still gets stuck - can’t find – mount point in fstab-- as usual. However now when I run a straight mount command it mounts correctly providing I do it as root
mount //192.168.10.153/Volume_1 /home/john/Desktop/NAS -o user=john,rw
Looking at the source code for mount.cifs the fstab check is very definitely built in. The rw option may not be needed but the source checks independently of the fstab entry.
Initial impressions are that directory and file navigation is a little slower than it was. Transfer speeds may be as well.
The source code leaves me wondering about a couple of other things. Is there a way that I can assign a name to my nas that the system will pick up correctly rather than using an ip address?
Failing all is there an option that can be set to allow a user to use the mount command. Seems that will be needed for the umount.cifs…Yast user flags for instance. There doesn’t seem to be any doc on what all of these can do. The help button help is pathetic.
Sorted. It now runs as it did but I had to recompile the source and change options. One thing for sure, something else may have changed elsewhere. Following the upgrade the max data rate looks as if it is now lower. VLC is jerky at max playback speed. I had a huge number of windows open though so need to check that more carefully really.
One possible side effect but could be down to a busy machine – unmount.cifs didn’t the 1st time I used it. I may have opened the mount point folder too soon. It wont umount if it’s in use and that would explain that aspect. Tried again and all ok, It didn’t ask for root privileges.
The error msg when user use is partly enabled states that samba have disabled it because distro’s have been issuing it enabled without it being security checked. This fits in with what I could find when I searched around last time before rolling these utilities back to 11.3. There may be cases of remote execution causing problems but in terms or read write access it’s a case of people asking if it’s secure. There is no proof - so it’s been disabled. Proof is a difficult and expensive thing to obtain.
As far as security goes no data server of any sort should allow access without a password so I have some trouble understanding why it’s been crippled. If a server is left open - well that’s how it should be and mount.cifs will allow it to be mounted to any directory that the mounter owns. Otherwise it asks for the password and wont mount without it. The server wont allow access without one if it’s set up that way anyway.:sarcastic: The server may well be running linux and cifs. What an interesting thought.
I’m already tearing my hair out again.
This man entry seems to have changed since I last looked and has been expanded a lot but I am fairly sure my command line came from elsewhere. It took a long time to find, also the reason for the crippling.