Join Log in
Score:1
avatar Ubuntu

Mounting SMB Shares in Fstab issues

cn flag
Havock

I just upgraded my file server from 16.04 to 20.04 and everything seems to be working except for my SMB mounts on my Ubuntu computer. I can access the SMB shares on my Windows computer but on my Ubuntu 18.04 computer I can't get the shares mounted in fstab.

If I mount the shares from the command line (command below) it is mounted just fine.

sudo mount -t cifs -o username=username,vers=3.0 //192.168.1.116/Share /mnt/Share/

However when I try to mount the share in fstab (command below) the smb share is not mounted.

//192.168.1.116/Share  /mnt/Share  cifs  credentials=/home/user/.smbcredentials,vers=3.0,iocharset=utf8,sec=ntlmssp  0  0

After doing a sudo mount -a and trying a ls I get:

ls: cannot access 'Share': Operation not supported

and when I do a smbclient -L //192.168.1.116 I get:

protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE

Update:

When I do a

sudo mount -t cifs -o credentials=/home/user/.smbcredentials,vers=3.0,iocharset=utf8,sec=ntlmssp //192.168.1.116/Share /mnt/Share/

The SMB share is mounted properly.

When I do a

smbclient -L //192.168.1.116 -d 0

I get the same result:

protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE.

dmesg -t | grep -e CIFS returns:

CIFS VFS: cifs_mount failed w/return code = -95

When I check dmesg with the debug turned on I get a lot of:

/build/linux-Dh1oQA/linux-4.4.0/fs/cifs/cifsfs.c: CIFS VFS: in cifs_statfs as Xid: 9405245 with uid: 1000

/build/linux-Dh1oQA/linux-4.4.0/fs/cifs/cifsfs.c: CIFS VFS: leaving cifs_statfs (xid = 9405245) rc = -95

/build/linux-Dh1oQA/linux-4.4.0/fs/cifs/inode.c: CIFS VFS: in cifs_revalidate_dentry_attr as Xid: 9405247 with uid: 1000

/build/linux-Dh1oQA/linux-4.4.0/fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate_dentry_attr (xid = 9405247) rc = -95

87
0 + 0
heynnema avatar
ru flag
heynnema
It might be because they've removed SMB1 support, for security reasons. There's a way to re-enable it in /etc/samba/smb.conf, but of course, it's not recommended. I can't speak much about the hows and whys. I do have the smb.conf mods if you require it.
1
Reply
cn flag
Havock
I thought the vers=3.0 in my fstab was forcing the client to connect using SMB 3 instead on 1?
0
Reply
heynnema avatar
ru flag
heynnema
Just curious... have you rebooted .116? Are you running Ubuntu on .116 and the client computer? What version Windows? Was this working before you updated the server to 20.04?
0
Reply
cn flag
Havock
@heynnema .116 has been rebooted a few times. Everything was running just fine before I upgraded. The Samba shares work in Both Win7 and Win10. Ubuntu 20.04 on .116 and 18.04 on the client.
0
Reply
Score:0
avatar Ubuntu
cn flag
Havock

Not sure what happened but I was able to get this issue resolved.

I decided I'd start over and did a sudo umount /mnt/Share(s). After unmounting each directory I was about to use sudo mount -a and have my mount points in fstab all mount properly.

The clue was in an answer that is no longer available. The answer author (iirc @heynnema) asked me to put file_mode=0777,dir_mode=0777 in my fstab for a mount.

Fresh eyes this morning noticed that the directory was highlighted. A quick ls -l showed me it was 777 which wasn't right. I wasn't able to change it by adjusting fstab so I figured I'd start fresh again. Seems it worked this time around.

In the end I added to my;

smb.conf file

min client protocol = NT1
max client protocol = SMB3

/etc/fstab

vers=3.0

Even with min client protocol = NT1. The vers=3.0 was required.

0 + 0
cn flag
Havock
The helpful answer isn't available any more but I summarized what the resolution ended up being.
0
Reply
heynnema avatar
ru flag
heynnema
Glad you got it working! Your `max client protocol = SMB3` is probably incorrect though, as SMB3 should probably be NT3, or you could probably just leave the entire line out of smb.conf.
0
Reply
Score:0
Pircs avatar Ubuntu
us flag
Pircs

Would you try debug for smblient with?

smbclient -L //192.168.1.116 -d 0

Are you able to mount via the command line using the options and credentials file from fstab?

sudo mount -t cifs -o credentials=/home/user/.smbcredentials,vers=3.0,iocharset=utf8,sec=ntlmssp //192.168.1.116/Share /mnt/Share/

What are you getting in dmesg for CIFS errors?

dmesg -t | grep -e CIFS

We can also enable debug of the cifs module.

modprobe cifs
echo 'module cifs +p' > /sys/kernel/debug/dynamic_debug/control
echo 'file fs/cifs/* +p' > /sys/kernel/debug/dynamic_debug/control
echo 7 > /proc/fs/cifs/cifsFYI

and disable it with.

echo 0 > /proc/fs/cifs/cifsFYI

Check dmesg for the cifs module debug output also.

0 + 0
cn flag
Havock
When I do a () I get the same result: protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE. Using sudo mount -t cifs -o credentials=/home/user/.smbcredentials,vers=3.0,iocharset=utf8,sec=ntlmssp //192.168.1.116/Share /mnt/Share/
0
Reply
heynnema avatar
ru flag
heynnema
@Havock Did you substitute your real userid for "user" in the above command?
0
Reply
cn flag
Havock
@heynnema eventually I did :) Even with the proper userid it didn't work
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.