Comment # 1 on bug 1194945 from Enzo Matsumiya

Hi, thanks for the detailed report.

Unfortunately I couldn't reproduce the issue with neither .72 release nor with
the latest .106. Could you try using the latest as well just so we're on the
same page please?

Also please provide the packet capturing with the umount time frame, e.g.:

# <mount share>
# tcpdump -s 0 -w /tmp/trace.pcap & pid=$!
# sleep 3
# umount /mnt
# sleep 3
# kill $pid

Another observation: IIUC, this is failing from an application "app" you're
using, right? i.e. mount and umount (among other commands) are being issued by
the application.

Is it possible you can try a simple manual test? Only mount and umount right
after is enough for now.

My understanding so far:
cifs will try to access some path components sometimes, in this case via
cifs_statfs() function, and it it's possible it's getting STATUS_ACCESS_DENIED
from the server for the \company_users\ link/dir, but your app is translating
that error to errno 32 (broken pipe) and bailing immediatelly as a fatal error
(which it's not always the case for cifs).

This is all guesswork, but further testing will confirm what debugging path
should we follow here.