I found this in my dmesg log:
[ 3564.638017] No dialect specified on mount. Default has changed to a
more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To
use the less secure SMB1 dialect to access old servers which do not
support SMB3 (or SMB2.1) specify vers=1.0 on mount.
[ 3583.010893] CIFS VFS: Autodisabling the use of server inode numbers
on \\192.168.0.190\tank. This server doesn't seem to support them
properly. Hardlinks will not be recognized on this mount. Consider
mounting with the "noserverino" option to silence this message.
The server uses samba Version 4.5.12-Debian and the file system is zfs
provided by zfs on linux through the official debian package.
The case sensitive setting is not set, so it should be in "auto" mode.
When setting case sensitive to true, the wrongly-cased path returns
a file not found error.
The client uses cifs-utils 6.8, from the debian repos as well. The mount
is also behind autofs. The kernel is 4.17.0-amd64.
The mount parameters are: guest,iocharset=utf8,uid=1000,gid=1000
On 2018-08-19 12:17 PM, Steve French wrote:
You might check if the server is reporting "UniqueIds" correctly in the protocol
(we get the inode number by default from what the server returns, but
turn off that feature and autogenerate them if the server returns illegal
inode numbers such as '0'). We log a warning to dmesg if using the
server reported inode number is disabled.
Which dialect is this SMB3 (default vers=3.0) or CIFS (vers=1.0)?
What is the server file system type under Samba (ext4? btrfs? xfs?)
Also would be useful to know if you considered turning on case sensitivity
in smb.conf (on the server for the share, if using SMB2.1 or later)?
If you are using the default dialect for more recent kernels
this seems more plausible (the problem you report) but extremely
unlikely with cifs (vers=1.0) especially due to the CIFS Unix Extensions
since if you searched for the file with different case you would have
gotten a file not found for the other one (and samba should always
report inode numbers correctly).
On Sun, Aug 19, 2018 at 11:10 AM Simon <git@xxxxxxxx> wrote:
I'm using a library that detects if two paths are the same file by
comparing the dev and ino numbers of the files. When using the library
on a mounted samba share (with cifs), the inode numbers differ when the
path's case is different. I'd like to know if there's a way to get
around this issue and detect that they are in fact the same file.
For instance, "GoodFellas (1990)" gives me {dev: 46, ino: 10248}
and "Goodfellas (1990)" gives me {dev: 46, ino: 11984}
Upstream bug: https://github.com/BurntSushi/same-file/issues/41
