I tried some experiments with Samba on ext4 and didn't see the same
problem (where "stat /mnt/file" and "stat /mnt/FILE" caused cifs to
notice the inode number conflict with two 'different' files having the
same inode number)
Probably safer in your case to run with case sensitivity = on in smb.conf
On Sun, Aug 19, 2018 at 11:55 AM Simon <git@xxxxxxxx> wrote:
>
> 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
> >
> >
> >
--
Thanks,
Steve
