I have a windows share mounted via CIFS on an ubuntu server. I need to a way to know when a new file has been added to the Windows share. I tried this inotify program:
http://www.thegeekstuff.com/2010/04/inotify-c-program-example/
Which works fine with standard directories, but is unable to catch any CIFS changes. I don't neccessarily need to use inotify, although I would like to, but any suggestions on how to accomplish getting file create notifications would be great.
I have also been working on this and ran into the same issue - it seems (after a little trawling on google) that, unfortunately, it is not possible to use inotify on CIFS mounted partitions - The following was in a redhat forum post from a couple of years ago:
"Currently, no this isn't possible with CIFS. The VFS hooks to allow a filesystem to set up extra notfications were removed recently. The only "user" of them was CIFS and it never worked properly anyway. The kernel interface for this had serious problems too.
I think Steve has plans to reimplement it, but it's a major project that means adding new functionality to the VFS layer of the kernel."
While this was a couple of years ago, it seems we are no closer to having this facility available - shame, I could have really used it too!
I too ran into this and reached the same conclusion as Stephen Sullivan (CIFS + inotify = no go).
However, since my workflow happened to depend on both remote mounts and auto-compile tools that rely on inotify, I ended up building a (fairly desperate & hacky) solution which basically just uses polling to watch for changes and then touches the same files again on the mounted side, which does seem to fire off inotify events. It is not my proudest moment.
Having said that, it does work, so, enjoy: http://github.com/rubyruy/watchntouch
Old topic, still important! My answer to this is: "it depends!". From my empirical tests at this time, the behavior is quite clear. If the Linux host initiates the filesystem event [upon a CIFS mount], then inotify will see it just fine. If the Windows machine which hosts the CIFS mount initiates the filesystem event, then inotify [on the Linux machine] will not see it at all.
If your goal is for the Linux host to get notification that the Windows host created or wrote to a file, then you are out of luck. Since this is probably the most desired use of this mechanism, it does make this subtle "it depends" answer not so terribly useful!
Got that kind of problem for my OCR project which monitors a remote samba share to feed Tesseract (https://github.com/deajan/pmOCR)
Ended up using a drop-in inotifywait replacment based on polling directories, see https://github.com/javanile/inotifywait-polling
Indeed there are python solutions as fsobserver that allow polling mode too.
just wanted to add that I also recently ran into this issue when using Azure Container Instances with a Azure Files mounted into the system. Inotify also fails to see any changes on the Azure Files mount, I guess since it's using CIFS.
I stumbled upon a useful tool that can also use polling instead of inotify.
It's called fswatch.
https://emcrisostomo.github.io/fswatch/
I had to create my own package for the Alpine based container in question, but it wasn't too difficult using the instructions on Alpine's site.
https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package
Here's my APKBUILD if anyone finds it helpful (shamelessly based on the sample provided by Alpine! :) )
# Contributor:
# Maintainer:
pkgname=fswatch
pkgver=1.17.1
pkgrel=0
pkgdesc="A cross-platform file change monitor with multiple backends"
url="https://emcrisostomo.github.io/fswatch/"
arch="all"
license="GPL"
depends=""
depends_dev="alpine-sdk"
makedepends="$depends_dev"
install=""
subpackages="$pkgname-doc"
source="https://github.com/emcrisostomo/$pkgname/releases/download/$pkgver/$pkgname-$pkgver.tar.gz"
builddir="$srcdir/$pkgname-$pkgver"
prepare() {
default_prepare
# this function can be omitted if no extra steps are needed
}
build() {
./configure --prefix=/usr \
--sysconfdir=/etc \
--mandir=/usr/share/man \
--infodir=/usr/share/info \
--localstatedir=/var \
--disable-wxwidgets \
--disable-qt
make
}
check() {
make check
}
package() {
make DESTDIR="$pkgdir" install
}
sha512sums="c38e341c567f5f16bfa64b72fc48bba5e93873d8572522e670e6f320bbc2122f fswatch-1.17.1.tar.gz"
I used a multi-stage Dockerfile and then copied the resulting package into the target container. I had to use the --allow-untrusted flag to do the install.
apk add --allow-untrusted /tmp/fswatch-1.17.1-r0.apk
Here's the relavent section of the Dockerfile
## ==========
## FSWatcher Builder
# IMPORTANT: Build this package on the same Alpine version used by the target container
FROM ${ALPINE_CONTAINER}:${ALPINE_VERSION} AS fswatch
COPY /scripts/fswatch.apkbuild /tmp/APKBUILD
USER root
WORKDIR /app
RUN apk upgrade --update-cache --available && apk add alpine-sdk sudo && rm -rf /var/cache/apk/*; \
adduser -D -h /home/build build; \
addgroup build abuild; \
mkdir -p /var/cache/distfiles; \
chmod a+w /var/cache/distfiles; \
chgrp abuild /var/cache/distfiles; \
chmod g+w /var/cache/distfiles; \
abuild-keygen -a -i -n
USER build
WORKDIR /home/build
RUN abuild-keygen -a -n; \
mkdir fswatch; \
cd fswatch; \
cp /tmp/APKBUILD ./; \
dos2unix ./APKBUILD; \
abuild checksum; \
abuild -r
UPDATE: Here's my entrypoint.sh as well, where I run fswatch (I had to use a bash shebang on debian based system...YMMV.)
#!/bin/sh
set -e
{ /usr/bin/fswatch -0 -o -r -m poll_monitor /etc/nginx/ssl | while read -d "" event;do echo "$(date -Ins) Event Fired: ${event}";/opt/reload.sh;done; } &
exec "$@"
And the reload.sh script:
#!/bin/sh
set -e
/usr/sbin/nginx -s reload && echo "nginx reloaded"
Hope those are useful for someone in the same boat!
It can be done.. sort of
If you set up an webdav server and include the share as webdav location, you can monitor the location on you samba server while accessing it through webdav from your windows machine.
The big problem with this is that file permissions are a b*tch... as usual with apache2 webdav since its missing pass-through authentication
For Windows hosts running Linux docker containers there is a detailed article on t his issue with a provided solution that works "docker-windows-volume-watcher": http://blog.subjectify.us/miscellaneous/2017/04/24/docker-for-windows-watch-bindings.html
Looks like support is not coming any time soon from Linux implementation of CIFS inotify.
If you flip this around and have a CIFS share served from a Linux host, and have a network client upload files to this share, then inotify on the server will be able to detect when a new file has been uploaded (via the CLOSE_WRITE event).
I suggest using fileschanged
I just tested it with mounted CIFS drives from Windows. It worked like a charme with almost no latency or server load. It seems pretty reliable.
sudo apt-get install fileschanged
To monitor/trigger:
fileschanged folder/
The output will look like this:
folder/test1
You can pipe the output:
fileschanged
folder/
|
while read -r filename; do
filename="${filename##*/}"
echo "Triggering $filename" >> /var/log/fileschanged.log
# do whatever you like with $filename
done
I have already dealt with the topic for my document search engine. And the following part of the project developed. I have committed the first draft. Unfortunately, I have to take care of my other projects first. Fish out the "smbclient" command. When I'm ready, you can use this project as a lib or start it as a system hook app which will give the info to other apps.
https://github.com/stefanwerfling/smbeye/blob/main/src/inc/SmbClientNotif.ts
I hope this can serve as a workaround for you. Or you wait until I'm ready. ;)
