On Sat, 19 May 2018 17:54:28 +0100, RobH  declaimed the
following:

>epi@raspberrypi:~ $ sudo mount //NAS/CCTV/PiZero /mnt/CCTV/PiZero
>Password for root@//NAS/CCTV/PiZero:  *********
>mount error(115): Operation now in progress
>Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
>
 Unless you know for certain that the name NAS resolves to YOUR NAS
device, you should probably be using YOUR IP# there.

>
>First I mounted :
>pi@raspberrypi:~ $ sudo mount //NAS/CCTV/PiZero /mnt/CCTV/PiZero
>Password for root@//NAS/CCTV/PiZero:  *********
>mount error(115): Operation now in progress
>Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
>
 No... You ATTEMPTED to mount it -- the mount did not complete
successfully; likely because the name NAS is not pointing to your device
but to something defined somewhere else (and how it is visible to your
network I have no idea).

>pi@raspberrypi:~ $ python intruder_recmotion.py
>Traceback (most recent call last):
>   File "intruder_recmotion.py", line 37, in pi@raspberrypi:~ $
>     shutil.copyfile(RAMname, NASname)
>   File "/usr/lib/python2.7/shutil.py", line 83, in copyfile
>     with open(dst, 'wb') as fdst:
>IOError: [Errno 13] Permission denied:
>'/mnt/CCTV/PiZero/2018-19-19_17.43.42.h264'
>
 Expected if you have a partial mount success -- that is, it thinks it
is mounted, but you have no privileges to do anything on that location....
OR: the non-mounted directory is not writable by your user account. Try
running

 sudo chown pi:pi /mnt/CCTV/PiZero

and maybe for safety also

 sudo chown pi:pi /mnt/CCTV


>Whilst the script was running, ie 15 seconds after the video, I then ran
>
>pi@raspberrypi:~ $ ls /run/shm
>
>2018-16-16_11.25.36.h264  2018-17-17_20.30.31.h264  2018-19-19_17.36.16.h264
>2018-17-17_18.01.07.h264  2018-18-18_10.04.24.h264  2018-19-19_17.40.13.h264
>2018-17-17_20.25.53.h264  2018-18-18_10.15.22.h264  2018-19-19_17.43.42.h264
>2018-17-17_20.26.43.h264  2018-19-19_17.25.50.h264
>2018-17-17_20.28.34.h264  2018-19-19_17.31.32.h264
>
>As well as
>pi@raspberrypi:~ $ ls /dev/shm
>
>2018-16-16_11.25.36.h264  2018-17-17_20.30.31.h264  2018-19-19_17.36.16.h264
>2018-17-17_18.01.07.h264  2018-18-18_10.04.24.h264  2018-19-19_17.40.13.h264
>2018-17-17_20.25.53.h264  2018-18-18_10.15.22.h264  2018-19-19_17.43.42.h264
>2018-17-17_20.26.43.h264  2018-19-19_17.25.50.h264
>2018-17-17_20.28.34.h264  2018-19-19_17.31.32.h264
>
>It very well looks like the files are created, but where to.

 Interesting -- it appears that your system sees /run/shm and /dev/shm
as the same location.

 Those files are located in a shared RAM(disk) -- which is why you'll
want the unlink() statement once the mount works. Though why you show files
going back three days if they are in RAM I don't know -- Unless you haven't
rebooted the system in all that time, and my script was silently dying on
the copyfile() so the unlink() never ran. The unlink() is supposed to
delete the temporary file from RAM after it is copied to /mnt/whatever...




--
 Wulfraed                 Dennis Lee Bieber         AF6VN
 wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

--- SoupGate-Win32 v1.05