[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CABVgOSkHoVcRQLGVTZZ1andSY4UHqoRwLdyiTHh9KTQ4m3av9w@mail.gmail.com>
Date: Sat, 11 Sep 2021 06:21:16 +0800
From: David Gow <davidgow@...gle.com>
To: Arthur Marsh <arthur.marsh@...ernode.on.net>
Cc: Shuah Khan <skhan@...uxfoundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Brendan Higgins <brendanhiggins@...gle.com>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@...r.kernel.org>
Subject: Re: After KUnit update for Linux 5.15-rc1 - unable to share VFAT
filesystem via samba
On Fri, Sep 10, 2021 at 8:02 PM Arthur Marsh
<arthur.marsh@...ernode.on.net> wrote:
>
>
> Hi, I have been sharing an old VFAT formatted hard disk on one pc to
> another using Samba and sometime after kernel 5.14.0 it stopped working (apparently no longer being shared as the mount.smbfs command
> on the client failed with error -13 yet mount.smbfs still worked for
> ext3 filesytems shared from the same machine which had the VFAT
> filesystem).
> The only error I saw on the machine with the VFAT formatted hard disk
> was the output of the mount command had truncated the name of the
> mount to only include the first 4 characters of the base name of the
> mount point.
> e.g. when VFAT filesystem was mounted on /mnt/victoria, the output of
> the mount command showed the filesytem mounted on /mnt/vict
>
I can't reproduce this on my machine (which is openSUSE Tumbleweed
with their "vanilla" 5.14 kernel package on x86_64, mounting a FAT16
filesystem).
# mount /dev/sda1 /mnt/victoria
# mount | grep vic
/dev/sda1 on /mnt/victoria type vfat
(rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
# uname -a
Linux patpat 5.14.0-1-vanilla #1 SMP Mon Aug 30 07:01:36 UTC 2021
(dc06e24) x86_64 x86_64 x86_64 GNU/Linux
I can try it again on an older i386 machine, but I doubt that'd change
things: this doesn't smell architecture-specific to me.
This seems a lot more like it's something to do with /proc/mounts or
similar, rather than a FAT specific issue (and, unless something
really strange has happened with the CONFIG_FAT_DEFAULT_CODEPAGE
config option, which I doubt), this change shouldn't affect anything
at all when KUnit isn't enabled and used. I suspect it just shows up
in the bisect because it's basically the only change in fs/fat for a
while.
The bisect against the whole kernel tree seems likely to be of more use.
-- David
Powered by blists - more mailing lists