As I had already noted.
Did you create the necessary entry in your smb.conf?
[global]
[...]
client min protocol = NT1
Hmmm… There is no smb.conf in /etc/samba. Only the folder “private”. Either my fstab entry was working all along without this file or it needed this file which has somehow been deleted recently.
You can’t copy and paste every option you have in fstab to the mount command. Especially the ones that tell it to auto-mount, FS check, etc.
man mount.cifs
You have to format the command properly first. Then you can start troubleshooting properly.
You also didn’t say what got upgraded. I guessed on the 3 most likely packages to be upgraded that would cause a CIFS mount issue.
Then I suggest you create the file - as this will instruct the smbclient it is OK to use the old unsafe protocol.
Ulp…foolish of me. Here goes - in the below line all I believe are valid options. However I get “Bad usage” as the response. Also, I can see that cifs-utils as well as smbclient were updated. The Kernel list shows that 6.2.16-1 is what is running though I don’t know how to figure out when it was updated. I can see it is not labeled “LTS”.
RR-Manjaro% sudo mount -t cifs //192.168.9.8/ramkumarr /mnt/ramkumarrNAS username=ramkumarr,password=xxxxxxxx,vers=1.0,uid=1000,gid=1000,iocharset=utf8,noauto,_netdev,noatime
I tried this too… did not help. The above mount command gives “Bad usage”, neither does the fstab line work.
Your mount line in fstab is not equivalent to the usage on commandline.
You would need to pass your options with the -o option to the mount command - otherwise you will get a bad usage response. Not all fstab options make sense when uing a manual mount.
mount -t cifs -o bla1,bla2,bla3 //ip.x.y.z /path/to/mount/point
The most oommon cause as to why users keep using fstab to mount is because the mount command does not allow for user mount.
There is other methods - like this one - which can be executed as user - no root required - supply credentials when challenged.
gio mount smb://ip.x.y.z/sharename
If you would like to explore that further there is this [root tip] [Utility Script] GIO mount samba share
Another common cause when Samba is acting up on Arch based system is AppArmor - the previously linked topic contains some info on this - although this is most relevant when sharing folders from a Manjaro system.
You need a -o before all the comma separated options.
And 6.1 is the latest LTS Manjaro kernel currently. It’s listed in Applications/Manjaro Settings under kernels through the GUI, and you can install/remove kernels there. (Or mhwd-kernel -i linux61 to install via command line.)
Yes of course I missed the -o though I read it in the manual … I’m definitely getting old. Thanks folks for being so patient with my ignorance + carelessness.
The corrected command below gives me mount error(22): Invalid argument
sudo mount -t cifs //192.168.9.8/ramkumarr /mnt/ramkumarrNAS -o username=ramkumarr,password=xxxxxxxx,vers=1.0,uid=1000,gid=1000,iocharset=utf8,noauto,_netdev,noatime
Thank you, I tried this and yes the share does get mounted on /run/user/1000/gvfs/smb-share...
@linux-aarhus did bring this up in his link he included, and I was replying to most of this on my phone. But I would highly recommend not using fstab for network mounts.
It’s really just creating a file with 10 lines or so, to create a systemd unit. Then just one command to start/mount it (and one to enable on startup). If other services rely on these mounts, it is fairly easy to build in that functionality too.
Another example: https://rayagainstthemachine.net/linux%20administration/systemd-automount/
The TimeOutSec and (TimeoutIdleSec for ondemand automounting) options are really handy for network mounts too.
Thanks for the links…they look straighforward enough and I should be able to set it up. But I am curious to understand why you make the above recommendation!
The list is rather long… But systemd.mount units are designed for just this purpose. (Plus so much more, most of which, you won’t even use.)
Some important ones for you, I would guess would be:
- It will slow your boot process (with your NAS down, or other whatever other issues, even appear to halt the boot process)
- If it fails, this is a much safer way to automatically remount and handle this scenario
- You can pick when you want it mounted during the boot process (
multi-user.targetis an easy choice that’s already there, and commonly used for this) - You make can make the service(s) that depend on this mount not start until the the mount succeeds
- It also works the other way around, for a safer way to shutdown the services it depends on
I highly recommend mount units as well. My reasons are explained in [root tip] [How To] Use systemd to mount ANY device
Several years ago I had issues with my network mounts as it was highly troublesome and error prone to use fstab - so I investigated what could be done with systemd - which lead me to mount and automount units.
They are really simple to work with - they are easy to understand - they are easy to maintain
Some years later I wrote these topics
Thanks very much, @Molski and @linux-aarhus for the very useful inputs. Makes plenty of sense. I will go about implementing these changes for my NAS.
Cheers - Ram
I followed this set of instructions. However the unit did not start; the message advised me to run journalctl -xe and lo and behold I was back to square 1: Error 22, invalid argument.
Apparent Solution: I downgraded to the latest LTS kernel 6.1 while rebooting and it worked! My old mountpoints are back! Thank you.
Glad to hear. I gave (guessed at) the 3 most likely culprits it stopping it from working after an update. That was one of them. (I only run LTS kernels myself.) That you had to use GIO to mount it sounded really off to me. (Never used that myself).
At least you are a little more future-proofed, and made your system more error tolerant just because of all this.
Win-win.
I see you tackled this problem, is there really no way to update the nas to accept a higher version than 1.0 though?
I very recently had a very strange error with one of my mounts, not network, but it suddenly just broke, I could no longer execute files from it.
The solution was changing the option user to nouser (that is also included in the defaults option, maybe try with that?).
Just an idea to play around with.
From a web search it looks like Buffalo NASs now support at least 2.0. I tried with vers=2.0 and it works.