| 2018-02-13 15:20:06 |
Dave Ford |
bug |
|
|
added bug |
| 2018-02-13 15:21:13 |
Dave Ford |
summary |
default vers value |
default vers value when mounting cifs shares with mount.cifs not working |
|
| 2018-02-13 15:23:04 |
Dave Ford |
description |
Firstly, apologies if this isn't a bug in cifs.mount - I know it's intimitly connected to a recent kernel updates which changed the default SMB version cifs connects with, but I'm having trouble distinguishing whether this behaviour is caused by the kernel change or a problem with cifs.
On a recently built 16.04.3 LTS box with kernel 4.4.0-109, I was able to mount to a network DFS share with the following
mount.cifs -o user=username //pathto/share /mountpoint
and after doing so, I was able to navigate through the mounted share, and through the underlying DFS structure with no problems. The mount command notably contained 'vers=1.0' - which was expected.
After updating the kernel to 4.13.0.32, if I run the same command, the share appears to mount, but I get a 'cannot access ...: Input/Output error' when trying to move through a DFS mount within the mounted filesystem.
Notably, the output from the mount command has 'vers=default'.
I understand from various sources, that the default SMB vers is now 3.0 - and if I mount this share explicitly with
mount.cifs -o user=username,vers=3.0 //pathto/share /mountpoint
Then I see 'vers=3' on the output from mount, and am able to use the share as expected.
The man page for the cifs.mount cmd still says the default is SMB1.0 (this appeared to be the case with a kernel previous to 4.13). The kernel sources now say the default is SMB 3.0 - which would also be find, if the share is mounted with vers=3.0.
But instead I'm seeing 'vers=default' - and I'm unsure as to what version of SMB it's actually trying to use (if any) - whatever it is, it doesn't work unless I explicitly set vers=3.0. |
Firstly, apologies if this isn't a bug in cifs.mount - I know it's intimitly connected to a recent kernel updates which changed the default SMB version cifs connects with, but I'm having trouble distinguishing whether this behaviour is caused by the kernel change or a problem with cifs.
On a recently built 16.04.3 LTS box with kernel 4.4.0-109, I was able to mount to a network DFS share with the following
mount.cifs -o user=username //pathto/share /mountpoint
and after doing so, I was able to navigate through the mounted share, and through the underlying DFS structure with no problems. The mount command notably contained 'vers=1.0' - which was expected.
After updating the kernel to 4.13.0.32, if I run the same command, the share appears to mount, but I get a 'cannot access ...: Input/Output error' when trying to move through a DFS mount within the mounted filesystem.
Notably, the output from the mount command has 'vers=default'.
I understand from various sources, that the default SMB vers is now 3.0 - and if I mount this share explicitly with
mount.cifs -o user=username,vers=3.0 //pathto/share /mountpoint
Then I see 'vers=3' on the output from mount, and am able to use the share as expected.
The man page for the cifs.mount cmd still says the default is SMB1.0 (this appeared to be the case with a kernel previous to 4.13). The kernel sources now say the default is SMB 3.0 - which would also be find, if the share is mounted with vers=3.0.
But instead I'm seeing 'vers=default' - and I'm unsure as to what version of SMB it's actually trying to use (if any) - whatever it is, it doesn't work unless I explicitly set vers=3.0.
Thanks
Dave |
|
| 2018-02-13 15:30:06 |
Ubuntu Kernel Bot |
linux (Ubuntu): status |
New |
Incomplete |
|
| 2018-02-13 16:03:38 |
Dave Ford |
tags |
|
apport-collected xenial |
|
| 2018-02-13 16:03:39 |
Dave Ford |
description |
Firstly, apologies if this isn't a bug in cifs.mount - I know it's intimitly connected to a recent kernel updates which changed the default SMB version cifs connects with, but I'm having trouble distinguishing whether this behaviour is caused by the kernel change or a problem with cifs.
On a recently built 16.04.3 LTS box with kernel 4.4.0-109, I was able to mount to a network DFS share with the following
mount.cifs -o user=username //pathto/share /mountpoint
and after doing so, I was able to navigate through the mounted share, and through the underlying DFS structure with no problems. The mount command notably contained 'vers=1.0' - which was expected.
After updating the kernel to 4.13.0.32, if I run the same command, the share appears to mount, but I get a 'cannot access ...: Input/Output error' when trying to move through a DFS mount within the mounted filesystem.
Notably, the output from the mount command has 'vers=default'.
I understand from various sources, that the default SMB vers is now 3.0 - and if I mount this share explicitly with
mount.cifs -o user=username,vers=3.0 //pathto/share /mountpoint
Then I see 'vers=3' on the output from mount, and am able to use the share as expected.
The man page for the cifs.mount cmd still says the default is SMB1.0 (this appeared to be the case with a kernel previous to 4.13). The kernel sources now say the default is SMB 3.0 - which would also be find, if the share is mounted with vers=3.0.
But instead I'm seeing 'vers=default' - and I'm unsure as to what version of SMB it's actually trying to use (if any) - whatever it is, it doesn't work unless I explicitly set vers=3.0.
Thanks
Dave |
Firstly, apologies if this isn't a bug in cifs.mount - I know it's intimitly connected to a recent kernel updates which changed the default SMB version cifs connects with, but I'm having trouble distinguishing whether this behaviour is caused by the kernel change or a problem with cifs.
On a recently built 16.04.3 LTS box with kernel 4.4.0-109, I was able to mount to a network DFS share with the following
mount.cifs -o user=username //pathto/share /mountpoint
and after doing so, I was able to navigate through the mounted share, and through the underlying DFS structure with no problems. The mount command notably contained 'vers=1.0' - which was expected.
After updating the kernel to 4.13.0.32, if I run the same command, the share appears to mount, but I get a 'cannot access ...: Input/Output error' when trying to move through a DFS mount within the mounted filesystem.
Notably, the output from the mount command has 'vers=default'.
I understand from various sources, that the default SMB vers is now 3.0 - and if I mount this share explicitly with
mount.cifs -o user=username,vers=3.0 //pathto/share /mountpoint
Then I see 'vers=3' on the output from mount, and am able to use the share as expected.
The man page for the cifs.mount cmd still says the default is SMB1.0 (this appeared to be the case with a kernel previous to 4.13). The kernel sources now say the default is SMB 3.0 - which would also be find, if the share is mounted with vers=3.0.
But instead I'm seeing 'vers=default' - and I'm unsure as to what version of SMB it's actually trying to use (if any) - whatever it is, it doesn't work unless I explicitly set vers=3.0.
Thanks
Dave
---
AlsaDevices:
total 0
crw-rw---- 1 root audio 116, 1 Feb 13 12:02 seq
crw-rw---- 1 root audio 116, 33 Feb 13 12:02 timer
AplayDevices: Error: [Errno 2] No such file or directory
ApportVersion: 2.20.1-0ubuntu2.15
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found.
DistroRelease: Ubuntu 16.04
HibernationDevice: RESUME=UUID=4d912473-ae08-4591-886b-eff2cb5edfd9
InstallationDate: Installed on 2017-07-11 (217 days ago)
InstallationMedia: Ubuntu-Server 16.04.2 LTS "Xenial Xerus" - Release amd64 (20170215.8)
IwConfig: Error: [Errno 2] No such file or directory
Lsusb: Error: command ['lsusb'] failed with exit code 1:
MachineType: VMware, Inc. VMware Virtual Platform
Package: linux (not installed)
PciMultimedia:
ProcFB:
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.13.0-32-generic root=UUID=d702a195-430c-4bf2-9753-6618837863dc ro
ProcVersionSignature: Ubuntu 4.13.0-32.35~16.04.1-generic 4.13.13
RelatedPackageVersions:
linux-restricted-modules-4.13.0-32-generic N/A
linux-backports-modules-4.13.0-32-generic N/A
linux-firmware 1.157.15
RfKill: Error: [Errno 2] No such file or directory
Tags: xenial
Uname: Linux 4.13.0-32-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: oracle
_MarkForUpload: True
dmi.bios.date: 04/05/2016
dmi.bios.vendor: Phoenix Technologies LTD
dmi.bios.version: 6.00
dmi.board.name: 440BX Desktop Reference Platform
dmi.board.vendor: Intel Corporation
dmi.board.version: None
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 1
dmi.chassis.vendor: No Enclosure
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnPhoenixTechnologiesLTD:bvr6.00:bd04/05/2016:svnVMware,Inc.:pnVMwareVirtualPlatform:pvrNone:rvnIntelCorporation:rn440BXDesktopReferencePlatform:rvrNone:cvnNoEnclosure:ct1:cvrN/A:
dmi.product.name: VMware Virtual Platform
dmi.product.version: None
dmi.sys.vendor: VMware, Inc. |
|
| 2018-02-13 16:03:40 |
Dave Ford |
attachment added |
|
CurrentDmesg.txt https://bugs.launchpad.net/bugs/1749214/+attachment/5054389/+files/CurrentDmesg.txt |
|
| 2018-02-13 16:03:42 |
Dave Ford |
attachment added |
|
JournalErrors.txt https://bugs.launchpad.net/bugs/1749214/+attachment/5054390/+files/JournalErrors.txt |
|
| 2018-02-13 16:03:43 |
Dave Ford |
attachment added |
|
Lspci.txt https://bugs.launchpad.net/bugs/1749214/+attachment/5054391/+files/Lspci.txt |
|
| 2018-02-13 16:03:44 |
Dave Ford |
attachment added |
|
ProcCpuinfo.txt https://bugs.launchpad.net/bugs/1749214/+attachment/5054392/+files/ProcCpuinfo.txt |
|
| 2018-02-13 16:03:46 |
Dave Ford |
attachment added |
|
ProcCpuinfoMinimal.txt https://bugs.launchpad.net/bugs/1749214/+attachment/5054393/+files/ProcCpuinfoMinimal.txt |
|
| 2018-02-13 16:03:47 |
Dave Ford |
attachment added |
|
ProcEnviron.txt https://bugs.launchpad.net/bugs/1749214/+attachment/5054394/+files/ProcEnviron.txt |
|
| 2018-02-13 16:03:48 |
Dave Ford |
attachment added |
|
ProcInterrupts.txt https://bugs.launchpad.net/bugs/1749214/+attachment/5054395/+files/ProcInterrupts.txt |
|
| 2018-02-13 16:03:49 |
Dave Ford |
attachment added |
|
ProcModules.txt https://bugs.launchpad.net/bugs/1749214/+attachment/5054396/+files/ProcModules.txt |
|
| 2018-02-13 16:03:50 |
Dave Ford |
attachment added |
|
UdevDb.txt https://bugs.launchpad.net/bugs/1749214/+attachment/5054397/+files/UdevDb.txt |
|
| 2018-02-13 16:03:54 |
Dave Ford |
attachment added |
|
WifiSyslog.txt https://bugs.launchpad.net/bugs/1749214/+attachment/5054398/+files/WifiSyslog.txt |
|
| 2018-02-13 16:07:23 |
Dave Ford |
linux (Ubuntu): status |
Incomplete |
Confirmed |
|
| 2018-02-13 18:49:50 |
Joseph Salisbury |
linux (Ubuntu): importance |
Undecided |
Medium |
|
| 2018-02-13 18:49:53 |
Joseph Salisbury |
linux (Ubuntu): status |
Confirmed |
Incomplete |
|
| 2018-02-13 18:50:19 |
Joseph Salisbury |
tags |
apport-collected xenial |
apport-collected needs-bisect xenial |
|
| 2018-02-14 14:02:35 |
Dave Ford |
tags |
apport-collected needs-bisect xenial |
apport-collected kernel-fixed-upstream needs-bisect xenial |
|
| 2018-04-16 04:17:30 |
Launchpad Janitor |
linux (Ubuntu): status |
Incomplete |
Expired |
|
