SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
This is so non-root users can mount the share to /mnt/zzz. I've had it like this for a very long time, and it always worked.
To make a long story short, with Slackware 14.2:
1) mount //10.0.0.2/zzz/shared no longer works, it gives "No such file or directory" error. It DOES work as root.
2) mount /mnt/zzz works as it always had and appears to now be the only way to make this work now for non-root users.
This is not the old permissions problem where mount.cifs was by default not setuid root, because if mount.cifs is setuid root, #1 above still doesn't work for non-root users. With Slackware 14.1, that was all that was needed to get #1 above to work.
My guess is that something was changed with mount, though I did not see it in the readme or changelog.
Anyone else notice this, and am I just missing something or was this an intentional change to mount?
And is there a way to get #1 above to work again? I have this in several systems, and when I upgraded my test box to Slackware 14.2, it stopped working. Either I figure a way to get it to work again, or I get to go change my systems to use #2 above, a bit of a PITA.
Distribution: Slackware 14.2 soon to be Slackware 15
Posts: 699
Original Poster
Rep:
1) According to man 8 mount.cifs (and yes, I already RTFM), it should work. In Slackware 14.1 it does. In Slackware 14.2, it does not.
2) Changing mount.cifs permissions fixed the permission problem in Slackware 14.1. It also fixes the permission problem in 14.2, but the error message is now different. This time, instead of complaining about permissions, it simply says "No such file or directory"
I still believe it is permission related, because it works as root.
I have this in systems that has been working for years. I'm not trying to set up something new or reinvent the wheel, this used to work. All I did was update my test bed from Slackware 14.1 to 14.2 (this is why I never do an update to a production system without first testing it in my development and test environments - had I done so, my production systems would have come to a screeching halt, people start lining up at my office door with pitch forks, etc. It can get ugly).
I have another 14.1 box that is clean, I'll test that version, update to 14.2, play with it more and chronicle my adventures, and post results here. I want to see if I can duplicate this on another box.
I have "user", not "users", and the manual says "user". It might ignore everything after the fourth character. I also don't set mode and file mode, and don't set uid or gid, nor do I use a credential file, I provide them on the line. Just for SNG, I tried it the way you have it, though the differences are subtle. Still did not work:
mount //10.0.0.2/zzz/shared
mount: //10.0.0.2/zzz/shared: No such file or directory
mount /mnt/zzz works like it always has.
What is interesting is that if I give it an invalid serivice:
mount //10.0.0.2/zzz/nothing_is_here
I get the exact same message, No such file or directory. The only reason I know the service is valid is that it works for root.
Distribution: Slackware 14.2 soon to be Slackware 15
Posts: 699
Original Poster
Rep:
First my conclusion:
SOMETHING CHANGED BETWEEN SLACKWARE 14.1 AND 14.2
It might very well be buried in some man or other documentation, but I haven't seen it. I'm not always all that observant, so it's very possible I just missed it.
Now the results of my adventures with mount on Slackware 14.1 and 14.2:
This has been duplicated on three clean Slackware 14.1 boxes and two clean Slackware 14.2 boxes:
-------------------------------------------
First we take a clean Slackware 14.1 box
ls -ls /sbin/mount.cifs
32 -rwxr-xr-x 1 root root 32228 Jun 25 2012 /sbin/mount.cifs
This is the default, and prevents non-root users from using mount. If they try, they get:
This program is not installed setuid root - "user" CIFS mounts not supported.
Note the error message clearly tells you why it does not work. This is easily remedied with:
chmod 4755 /sbin/mount.cifs
which gives us:
ls -ls /sbin/mount.cifs
32 -rwsr-xr-x 1 root root 32228 Jun 25 2012 /sbin/mount.cifs
Now, mounting with //10.0.0.2/zzz/shared works, like it always has.
-------------------------------------------
Now we switch to a clean Slackware 14.2 box and repeat all of the above.
ls -ls /sbin/mount.cifs
36 -rwxr-xr-x 1 root root 35464 Feb 11 2016 /sbin/mount.cifs
This is expected.
Here is where things change. An attempt to mount does NOT give us the expected message of This program is not installed setuid root. Instead it tells us:
mount //10.0.0.2/zzz/shared
mount: //10.0.0.2/zzz/shared: No such file or directory
Nothing about not being setuid, just no such file or directory.
So we try to mount with the mount point:
mount /mnt/zzz
This program is not installed setuid root - "user" CIFS mounts not supported.
This is expected, since mount.cifs is not setuid.
So:
chmod 4755 /sbin/mount.cifs
ls -ls /sbin/mount.cifs
36 -rwsr-xr-x 1 root root 35464 Feb 11 2016 /sbin/mount.cifs
Now we try to mount with the path:
mount //10.0.0.2/zzz/shared
mount: //10.0.0.2/zzz/shared: No such file or directory
Nothing changes.
Try to mount using mount point:
mount /mnt/zzz
And it works.
The change is that if you try to use the service/path, in this case //10.0.0.2/zzz/shared, it no longer works, but tells you "No such file or directory". This is not a setuid issue. AND, interesting enough, it works for root.
It's probably a simple change somewhere, but I haven't yet found it.
Oh, I haven't noticed that you're trying to use the server address+path instead of the mount point path.
In that case, I have the same behavior as yours.
This is likely an upstream thing. mount is part of the util-linux package. Slackware 14.1 came with 2.21.2 and Slackware 14.2 came with 2.27.1. There's a lot of changelogs between those versions, and I suspect you'd find something causing your mount problem in there. Now, whether that change was purposeful or a regression from another fix is up in the air until the offending commit is found.
Distribution: Slackware 14.2 soon to be Slackware 15
Posts: 699
Original Poster
Rep:
Fortunately, mounting via mount point works. I had to change my systems to use that instead address/path.
At the same time this is going on, I updated PHP to a newer version and got bit by the sftp bug that stops certain functions from working. When two very weird things happen at the same time, you start to wonder what you did to break it before you consider that it is an actual bug in the programs, and not something stupid you did. It was a very fun day...
Distribution: Slackware 14.2 soon to be Slackware 15
Posts: 699
Original Poster
Rep:
Quote:
Originally Posted by bassmadrigal
This is likely an upstream thing. mount is part of the util-linux package. Slackware 14.1 came with 2.21.2 and Slackware 14.2 came with 2.27.1. There's a lot of changelogs between those versions, and I suspect you'd find something causing your mount problem in there. Now, whether that change was purposeful or a regression from another fix is up in the air until the offending commit is found.
I suspect it was inadvertent. At the same time, I was dealing with a similar bug in PHP that was "accidentally" introduced by security "fix". That PHP bug was a bit obscure, but the mount problem? I'm rather surprised it slipped through their regression testing. I can't be the only one out there that lets non-root users mount shares via server/path.
This is likely an upstream thing. mount is part of the util-linux package.
It looks like a mount.cifs issue and that is not part of util-linux. Ook would need to compare using mount.cifs(8) directly, with the results of calling mount.cifs(8) indirectly via mount(8) to confirm which caused the changed behavior.
It looks like a mount.cifs issue and that is not part of util-linux. Ook would need to compare using mount.cifs(8) directly, with the results of calling mount.cifs(8) indirectly via mount(8) to confirm which caused the changed behavior.
Good catch! I don't know why I assumed cifs support was directly included in util-linux. Checking that shows there is a cifs-utils package, which 14.1 came with 5.5 and 14.2 came with 6.4. That's quite a bit smaller list, but it's still 129 commits.
@Ook, it might be beneficial to try building some of the releases between 5.5 and 6.4 to see if you can find where the issue popped up. The following will download the SlackBuild and the cifs-utils source from 5.6-6.3.
Then to build a particular version, just run the following, replacing the version number with the one you're intending to build.
Code:
VERSION=5.6 sh cifs-utils.SlackBuild
Then just upgrade the package and try to mount using the mount path. If you can duplicate, then try another version. Once you find version that introduced the issue, you can then view the commits for that release.
Note
The cifs vfs accepts the parameter user=, or for users familiar with smbfs it accepts the longer form of the parameter username=. Similarly the longer smbfs style parameter names may be accepted as synonyms for the shorter cifs parameters pass=,dom= and cred=.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.