Fix mount error(95): solved! Operation not supported SMB
15 Jan 2022 |
Fix mount error(95): solved! Operation not supported SMB |
Mounts SMB/CIFS shares with Linux
It’s common practice to mount Windows file shares on Linux using the SMB (Samba) implementation on Linux. the command is fairly straight forward.
# Install the required libraries if you haven't done that yet sudo apt update sudo apt install cifs-utils #Next mount the folder you want sudo mount -t cifs -o username=user_name //server_name_or_ip/share_name /mnt/share_name
The command above would:
- mount a server with the server_name or ip in the //server_name/share_name
- to a local /mnt/share_name folder
- so once the mount is complete you can access the shares contents by accessing the /mnt/share_name folder locally.
There are all sorts of options using this command , and when the share is created on the server , things like file access and permissions can be set. You can find a more complete description here on how to access and setup windows shares in Linux
The issue with Samba/Cifs mounts (on Synology and other SMB servers) error 95
Apparently there has been a change to the SMB (Samba) protocol . SMB1 was the default, which may not be sufficient because of upgraded security requirement tof SMB2 . So try setting the version to SMB2 with ver=2.0 Or ver=3.0 , more specifically in my case, Synology updated their SMB server and increased the security , and for those of us that do not keep up to date with the changes may find that our once working mount commands, are not failing with a message such as ..
mount error(95): Operation not supported
This obscure message with its “operation not supported” doesn’t shed light on the true cause of the issue. Online documentation is I was able to find online such as this Samba.Org mount.cifs document doesn’t really help much either. The trick is you can try dmesg to give you a more precise message.
mount error(95): Operation not supported Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
You can try dmesg to give you a more precise message
CIFS: VFS: Use of the less secure dialect ver=1.0 is not
recommended unless required for access to very old servers
CIFS: VFS: cifs_mount failed w/return code = -95
So if you haven’t a version set in your configuration (Your connection string) it will assume your client uses SMB1 as default, which may not be sufficient if the server you’re trying to connect to has upgraded there requirement to SMB2 . So try setting the version to SMB2 with ver=2.0 to see if it resolves the issue, as it did in my case,
So my Old error connection string
sudo mount -t cifs -o username=user_name //server_name/share_name /mnt/share_name
Revised working connection string. use vers=2.0 as part of your -0 witch attributes.
sudo mount -t cifs -o vers=2.0,username=user_name,password=password //server_name/share_name /mnt/share_name
Anyways this was just a quick post as it was a pain in the ass as to why all of a sudden my mounts to my Synology began failing.. hope it helps.
If you found this post useful , leave a comment below!
Windows Build Number
Microsoft Windows [Version 10.0.19042.985]
WSL Version
- WSL 2
- WSL 1
Kernel Version
5.4.72
Distro Version
Ubuntu 20.04
Other Software
Docker Desktop 3.3.3 (64133)
Docker version 20.10.6
Repro Steps
WSL2 — ubuntu 20.04 (from microsoft store)
mapping NFS/samba using cifs:
Mounting using cifs and username/ password works:
mount -t cifs -o username=somedomainuser@somefulldomainname //someserverfuldomainname/somesharename /somelinuxfolder
Listing shares from the same server using kerberos ticket (generated by kinit just before) works:
smbclient -k -L //someserverfuldomainname/somesharename
Mounting using cifs and sec=krb5 does not work,
mount -t cifs -o sec=krb5,vers=3.0 /someserverfuldomainname/somesharename /somelinuxfolder
-> it fails with error message mount error(95): Operation not supported:
and dmesg not listing any error.
Exactly same beahviour as in the WSL2 UBUNTU distro also in the container (from ubuntu 20.04 image) running in the Docker Desktop (set to use WSL2) start via compose file that has set:
cap_add: - ALL privileged: true
Expected Behavior
-
If the
smbclientcan list and also connect to the nfs/smb share using kerberos authentication, why the cifs can not ? -
Why the
mount -t cifscan connect only using username /password and using the kerberos ? -
What is the recommended / supported SECURE way how to map NFS/SAMBA shares from the WSL2 linux distros or Docker desktop containers based on linux images — any documentation ? Is there currently any ?
Actual Behavior
root@WEB-DT-027:/home/pavel# mount -t cifs -o sec=krb5,vers=1.0 //FQDNhost/sharedFolder /somelinuxmountpoint
mount error(95): Operation not supported
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
root@WEB-DT-027:/home/pavel# dmesg
[640512.077244] WSL2: Performing memory compaction.
[640515.629016] CIFS: Attempting to mount //devdockerhg01.od.rferl.org/docker-recording
[640573.129658] WSL2: Performing memory compaction.
[640634.184655] WSL2: Performing memory compaction.
[640695.261290] WSL2: Performing memory compaction.
root@WEB-DT-027:/home/pavel#
Diagnostic Logs
No response
#
9 лет, 9 месяцев назад
Темы:
5
Сообщения:
31
Участник с: 12 января 2013
Есть необходимость монтировать сетевые ресурсы…
Делаю следующее…
sudo mount.cifs //192.168.1.101/Work /mnt/STORAGE -o username=user
По логике весчей все должно быть нормально, но после ввода пароля получаю:
mount error(95): Operation not supported Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Решение оказалось простым, нужно добавить одну из опций —
sec=ntlm или sec=ntlmi или sec=ntlmv2 или
sec=ntlmv2i или sec=ntlmssp или sec=ntlmsspi
В моем случае это было:
mount.cifs //192.168.1.101/Work /mnt -o username=user,sec=ntlm
Более подробная информация есть тут — mount error(95): Operation not supported
Написал для тех кто столкнулся с подобной проблемой, надеюсь кому — то поможет.
selishii
#
4 года, 5 месяцев назад
Темы:
8
Сообщения:
75
Участник с: 03 июня 2016
Монтирую ресурсы с жесткого диска ‘Transcend_HDD’ подключенного к роутеру «ASUS» модель ‘RT-N65U-E8EC’:
sudo mount -t cifs //RT-N65U-E8EC/Transcend_HDD/Music /mnt/win/ -o user=MY_USER,pass=MY_PASS
mount error(112): Host is down
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)Чтобы избежать этого добавим версию cifs=1.0 ибо дальше уже будет Samba:
sudo mount -t cifs //RT-N65U-E8EC/Transcend_HDD/Music /mnt/win/ -o user=MY_USER,pass=MY_PASS,vers=1.0
Retrying with upper case share name
mount error(6): No such device or addressОказывается так монтируется от guest-пользователя:
sudo mount -t cifs //RT-N65U-E8EC/Transcend_HDD/Music /mnt/win/ -o guest,vers=1.0Нам нужно указать другой путь, без метки жесткого диска:
sudo mount -t cifs //RT-N65U-E8EC/Music /mnt/win/ -o user=MY_USER,pass=MY_PASS,vers=1.0
-
#1
With FreeNAS I’m replacing a Synology that I had mounted via SMB in a Ubuntu 16.04 machine. My fstab used to look like this with the creds stored and locked, worked great
Code:
//192.168.1.21/ds418 /mnt/ds418 cifs credentials=/home/myname/ds418creds,iocharset=utf8,sec=ntlm 0 0
Simply modifying this to the new mounts like this
Code:
//192.168.1.23/freenas /mnt/freenas cifs credentials=/home/myname/freenascreds,iocharset=utf8,sec=ntlm 0 0
Results in this error:
Code:
mount error(95): Operation not supported Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Watched a guy do it on a youtube video with his fstab laid out like this and it worked for him, but I got the same error as above so it feels like something is not right on the FreeNAS side that somehow only impacts Ubuntu connecting but I really don’t know.
Code:
//192.168.1.23/freenas /mnt/freenas/ cifs username=username,password=ispassword,rw,iocharset=utf8,noperm 0 0
I have no issue opening \10.0.1.23freenas in widnows with the same credentials I’m using in ubuntu. Big question here is why is none of this working with the FreeNAS box??
-
#2
Could be an SMB version thing so try adding vers=3.0 to your command.
-
#3
Thank you, that was it. Which I find concerning on a couple of levels. I guess the default is still some older version and there is no auto negotiation. Also seems Synology is leaving things with the older versions somewhere. For anyone else finding this:
Code:
//192.168.1.23/freenas /mnt/freenas cifs credentials=/home/username/freenascreds,vers=3.0,iocharset=utf8,sec=ntlm 0 0
-
#4
For any who still may find this. i had the same issue only in my case it was a raspberry pi with a synology.
Enable SMB3 on my synology did the trick
Forum rules
Before you post please read how to get help. Topics in this forum are automatically closed 6 months after creation.
-
cybermailer
unable to sudo mount -a
Hi,
i have a very confusing problem, i want to mount my synology nas to my home folder Multimedia.
my fstab looks like:
this worked for while but now it doesn’t
//synology/Multimedia /home/christopher/Multimedia cifs username=admin,passwd=xxx,domain=workgroup,user 0 0
i tried also:
//192.168.1.173/Multimedia /media/Multimedia cifs username=admin,password=xxx,iocharset=utf8,sec=ntlm,users 0 0
I can not try in terminal:
sudo mount -a
Error given:
mount error(95): Operation not supported
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Now i have no idea what to check….pls hlp
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 1 time in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
-
altair4
- Level 20
- Posts: 11021
- Joined: Tue Feb 03, 2009 10:27 am
Re: unable to sudo mount -a
Post
by altair4 » Wed Jan 10, 2018 9:10 am
Have you done a firmware update on your nas device lately? Or have you changed it’s configuration?
mount error(95): Operation not supported
You will get that error message if the SMB1 dialect has been disabled on the samba server running on the NAS.
Add another option to your original list:
//synology/Multimedia /home/christopher/Multimedia cifs username=admin,passwd=xxx,domain=workgroup,user,vers=2.0 0 0
If the samba server on the nas has SMB3 available you can also change the smb version to that:
//synology/Multimedia /home/christopher/Multimedia cifs username=admin,passwd=xxx,domain=workgroup,user,vers=3.0 0 0
Please add a [SOLVED] at the end of your original subject header if your question has been answered and solved.
-
cybermailer
Re: unable to sudo mount -a
Post
by cybermailer » Thu Jan 11, 2018 4:10 am
i tried several ways, maybe some kind of error with my mint distro, i will try to connect with my raspberry to my nas and look what will happen…
I have to mention that it worked for quite a while, than i had problems with the keyring thing therefore i blocks from auto mounting my devices…
Do i have to disable keyring?
-
vimes666
- Level 5
- Posts: 963
- Joined: Tue Jan 19, 2016 6:08 pm
Re: unable to sudo mount -a
Post
by vimes666 » Thu Jan 11, 2018 6:44 am
altair4 wrote:
You will get that error message if the SMB1 dialect has been disabled on the samba server running on the NAS.
It is the kernel update on the client that breaks the SMB1 functionality. I have this same problem on my mint 18.3 mate computer since I updated the kernel to 4.13.0.26.
My nas (also a synology) was not changed and still supports SMB1 through SMB3.
Forcing the client to SMB with ver 2.0 or 3.0 in fstab resolves the problem partly.
The problem I was faced after that, was that the permissions of every file or folder I touched via the the client pc was changed to 666 or 777!
I have not found a solution for that.
Forther info: the kernel update for 17.3 does not cause this problem.. I am reluctant at this point to try it on my main pc (18.1)..
If you think the issue is solved, edit your original post and add the word solved to the title.
-
altair4
- Level 20
- Posts: 11021
- Joined: Tue Feb 03, 2009 10:27 am
Re: unable to sudo mount -a
Post
by altair4 » Thu Jan 11, 2018 7:35 am
vimes666 wrote:It is the kernel update on the client that breaks the SMB1 functionality. I have this same problem on my mint 18.3 mate computer since I updated the kernel to 4.13.0.26.
My nas (also a synology) was not changed and still supports SMB1 through SMB3
It’s true that the 4.13 kernel changed the default cifs smb dialect from smb1 to smb3 but if your synology device supports both smb1 through smb3 you should not have noticed any difference when connecting to the device.
The problem I was faced after that, was that the permissions of every file or folder I touched via the the client pc was changed to 666 or 777!
You have control of that on the client with dir_mode, file_mode, and if necessary nounix options in your cifs statement.
Please add a [SOLVED] at the end of your original subject header if your question has been answered and solved.
-
vimes666
- Level 5
- Posts: 963
- Joined: Tue Jan 19, 2016 6:08 pm
Re: unable to sudo mount -a
Post
by vimes666 » Thu Jan 11, 2018 7:45 am
altair4 wrote:
You have control of that on the client with dir_mode, file_mode, and if necessary nounix options in your cifs statement.
dir_mode and file_mode only seem to have effect on what is displayed on the client side. On the server side 666 or 777 is set nevertheless 
I was already pondering about the nounix option, I will try that later today.
If you think the issue is solved, edit your original post and add the word solved to the title.
-
altair4
- Level 20
- Posts: 11021
- Joined: Tue Feb 03, 2009 10:27 am
Re: unable to sudo mount -a
Post
by altair4 » Thu Jan 11, 2018 7:48 am
@cybermailer
Open a terminal and run this command:
Or
Do you get this error message: protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE
Please add a [SOLVED] at the end of your original subject header if your question has been answered and solved.
-
vimes666
- Level 5
- Posts: 963
- Joined: Tue Jan 19, 2016 6:08 pm
Re: unable to sudo mount -a
Post
by vimes666 » Thu Jan 11, 2018 10:36 am
altair4 wrote:
You have control of that on the client with dir_mode, file_mode, and if necessary nounix options in your cifs statement.
I tried nounix, same problem. I think that I have to solve this on the synology side. However your suggestion to force the client into SMB 1.0 (viewtopic.php?f=157&t=261424#p1412849) did the trick! All is back to normal. Now I have at least some time to figure what going wrong with my permissions. Thanks a lot!
I am not sure wheather this helped the topic starter too.
If you think the issue is solved, edit your original post and add the word solved to the title.
-
cybermailer
Re: unable to sudo mount -a
Post
by cybermailer » Thu Jan 11, 2018 3:59 pm
in terminal i tried what you mentiond this is the output:
session setup failed: NT_STATUS_LOGON_FAILURE
Today i tried to connect my raspi with my nas -> without any problem -> therefore it must be a kernel/mint thing…
I connected my syn nas successfully with:
//synology/Multimedia /home/pi/Multimedia cifs username=xxx,password=xxx,domain=xxx,user 0 0
Youre right adding vers=1.0 seems to work for now.
//synology/Multimedia /home/pi/Multimedia cifs username=xxx,password=xxx,domain=xxx,vers=1.0,user 0 0
How should i go with this situation right now? Waiting for updates? Troubleshooting? Leaving all how it is now? thx for helping!!
-
altair4
- Level 20
- Posts: 11021
- Joined: Tue Feb 03, 2009 10:27 am
Re: unable to sudo mount -a
Post
by altair4 » Thu Jan 11, 2018 4:31 pm
cybermailer wrote:Youre right adding vers=1.0 seems to work for now.
//synology/Multimedia /home/pi/Multimedia cifs username=xxx,password=xxx,domain=xxx,vers=1.0,user 0 0How should i go with this situation right now? Waiting for updates? Troubleshooting? Leaving all how it is now? thx for helping!!
That’s the way the previous kernel default mounted the share so all you did was revert to how it used to be. It’s about the only thing you can do if your server only speaks SMB1.
Please add a [SOLVED] at the end of your original subject header if your question has been answered and solved.
-
altair4
- Level 20
- Posts: 11021
- Joined: Tue Feb 03, 2009 10:27 am
Re: unable to sudo mount -a
Post
by altair4 » Thu Jan 11, 2018 5:06 pm
I don’t know anything about the synology device so I cannot answer that question.
This topic is somewhat discombobulated so let me attempt to clarify because the original error could be the result of two different things.
Prior to Linux Kernel 4.13 the default version of SMB that cifs used was vers=1.0. If the server does not speak SMB1 because the server disabled it the Linux client user has to pass a vers=2.0 or vers=3.0 to gain access.
After Linux Kernel 4.13 the default version of SMB that cifs uses is vers = 3.0. If the server only speaks SMB1 or SMB2 the Linux client user has to pass vers=1.0 or vers=2.0.
One way to determine which version the server will accept is to run the smbclient -L //server command. smbclient at the moment only uses smb1 regardless of kernel so if you got this this error message protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE the server does not speak vers=1.0.
Please add a [SOLVED] at the end of your original subject header if your question has been answered and solved.
-
pcwolf
Re: unable to sudo mount -a
Post
by pcwolf » Mon Jan 15, 2018 6:19 pm
smbclient -L //Synology
smbclient -L //server
Both result in: «Connection to server failed (Error NT_STATUS_IO_TIMEOUT)»
Mint KDE 18.3 with kernel 4.13.0.26 here for me. Synology shares worked before kernel upgrade. Just another data point.
-Phil
-
altair4
- Level 20
- Posts: 11021
- Joined: Tue Feb 03, 2009 10:27 am
Re: unable to sudo mount -a
Post
by altair4 » Mon Jan 15, 2018 7:01 pm
Assuming there really is a host with the name Synology you did not get the protocol negotiation failed error so your device speaks smb1. You should be able to connect to it from the file manager.
If not you have a problem different from this topic/.
Please add a [SOLVED] at the end of your original subject header if your question has been answered and solved.
When mounting OSX 10.9.5 shares on Debian 8.2 with mount.cifs ver. 6.4:
mount error(95): Operation not supported
Credentials are not the issue. I can access them via smbclient. Mount reads domain and username from the credentials file correctly. I am running as root, so hopefully not a permissions issue.
The only difference I can find is in the flags reported in /var/log/system.log on the file sharing host. Accessing with mount.cifs lists no flags, smbclient lists a few. But the mount.cifs is working on another machine (archlinux) and also has no flags.
# smb client works fine
smbclient \\arnold\T800 -A ~ni_tools/passwd/arnold
Domain=[ARNOLD] OS=[Darwin] Server=[@(#)PROGRAM:smbd PROJECT:smbx-276.92.2]
smb: >
# mount
sudo mount -t cifs //arnold/T800 test -o credentials=~ni_tools/passwd/arnold,iocharset=utf8,uid=1000,gid=1000,rw -vv
domain=ARNOLD
mount.cifs kernel mount options: ip=157.229.27.130,unc=\arnoldT800,iocharset=utf8,uid=1000,gid=1000,user=lncd,,domain=ARNOLD,pass=********
mount error(95): Operation not supported
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
# get more info
echo 1 > /proc/fs/cifs/traceSMB
echo 1 > /proc/fs/cifs/cifsFYI
# whats going on? I don't know
dmesg |tail
[278115.106815] | 0x00 0x00 0x00 0x00 0x01 0x01 0x00 0x01 | _ _ _ _ _ _ _ _
[278115.106821] | 0x00 0x61 | _ a
[278115.107104] /build/linux-x1KGLI/linux-3.16.7-ckt11/fs/cifs/connect.c: RFC1002 header 0x26
[278115.107115] | 0x00 0x00 0x00 0x26 0xff 0x53 0x4d 0x42 | _ _ _ & xffffffff S M B
[278115.107123] | 0x2b 0x00 0x00 0x00 0x00 0x80 0x01 0x48 | + _ _ _ _ _ _ H
[278115.107129] | 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 | _ _ _ _ _ _ _ _
[278115.107135] | 0x00 0x00 0x00 0x00 0xff 0xff 0x5c 0x04 | _ _ _ _ xffffffff xffffffff _
[278115.107141] | 0x00 0x00 0x00 0x00 0x01 0x01 0x00 0x01 | _ _ _ _ _ _ _ _
[278115.107146] | 0x00 0x61 | _ a
[278115.107157] /build/linux-x1KGLI/linux-3.16.7-ckt11/fs/cifs/misc.c: checkSMB Length: 0x2a, smb_buf_length: 0x26
arnold: /var/log/system.log
### Successful mount from archlinux ###
Dec 17 15:11:42 arnold.wpic.upmc.edu digest-service[54605]: digest-request: uid=0
Dec 17 15:11:42 arnold.wpic.upmc.edu digest-service[54605]: digest-request: init request
Dec 17 15:11:42 arnold.wpic.upmc.edu digest-service[54605]: digest-request: init return domain: ARNOLD server: ARNOLD indomain was: <NULL>
Dec 17 15:11:42 arnold.wpic.upmc.edu digest-service[54605]: digest-request: uid=0
Dec 17 15:11:42 arnold.wpic.upmc.edu digest-service[54605]: digest-request: od failed with 2 proto=ntlmv2
Dec 17 15:11:42 arnold.wpic.upmc.edu digest-service[54605]: digest-request: user=ARNOLDlncd
Dec 17 15:11:42 arnold.wpic.upmc.edu digest-service[54605]: digest-request kdc: ok user=ARNOLDlncd proto=ntlmv2 flags:
### FAILED MOUNT ATTEMPT ###
Dec 17 14:39:11 arnold.wpic.upmc.edu digest-service[54210]: digest-request: uid=0
Dec 17 14:39:11 arnold.wpic.upmc.edu digest-service[54210]: digest-request: init request
Dec 17 14:39:11 arnold.wpic.upmc.edu digest-service[54210]: digest-request: init return domain: ARNOLD server: ARNOLD indomain was: <NULL>
Dec 17 14:39:11 arnold.wpic.upmc.edu digest-service[54210]: digest-request: uid=0
Dec 17 14:39:11 arnold.wpic.upmc.edu digest-service[54210]: digest-request: init request
Dec 17 14:39:11 arnold.wpic.upmc.edu digest-service[54210]: digest-request: init return domain: ARNOLD server: ARNOLD indomain was: <NULL>
Dec 17 14:39:11 arnold.wpic.upmc.edu digest-service[54210]: digest-request: uid=0
Dec 17 14:39:11 arnold.wpic.upmc.edu digest-service[54210]: digest-request: init request
Dec 17 14:39:11 arnold.wpic.upmc.edu digest-service[54210]: digest-request: init return domain: ARNOLD server: ARNOLD indomain was: <NULL>
Dec 17 14:39:11 arnold.wpic.upmc.edu digest-service[54210]: digest-request: uid=0
Dec 17 14:39:11 arnold.wpic.upmc.edu digest-service[54210]: digest-request: od failed with 2 proto=ntlmv2
Dec 17 14:39:11 arnold.wpic.upmc.edu digest-service[54210]: digest-request: user=ARNOLDlncd
Dec 17 14:39:11 arnold.wpic.upmc.edu digest-service[54210]: digest-request kdc: ok user=ARNOLDlncd proto=ntlmv2 flags:
### SMBCLIENT #####
Dec 17 14:57:48 arnold.wpic.upmc.edu digest-service[54353]: digest-request: uid=0
Dec 17 14:57:48 arnold.wpic.upmc.edu digest-service[54353]: digest-request: init request
Dec 17 14:57:48 arnold.wpic.upmc.edu digest-service[54353]: digest-request: init return domain: ARNOLD server: ARNOLD indomain was: <NULL>
Dec 17 14:57:48 arnold.wpic.upmc.edu digest-service[54353]: digest-request: uid=0
Dec 17 14:57:48 arnold.wpic.upmc.edu digest-service[54353]: digest-request: od failed with 2 proto=ntlmv2
Dec 17 14:57:48 arnold.wpic.upmc.edu digest-service[54353]: digest-request: user=WORKGROUPlncd
Dec 17 14:57:48 arnold.wpic.upmc.edu digest-service[54353]: digest-request kdc: ok user=ARNOLDlncd proto=ntlmv2 flags: NEG_KEYEX, ENC_128, NEG_NTLM2, NEG_ALWAYS_SIGN, NEG_NTLM, NEG_SIGN, NEG_TARGET, NEG_UNICODE