ftp causing invalid syntax

I found O'Reilly "Running Linux" was a very good introduction for a computer-literate newbie, but that was 2nd Edition - I have no idea what the new one is like. O'Reilly does a pile of other good stuff such as "Learning the bash Shell" for in-depth coverage and "Linux in a Nutshell" when you know the background and just need the syntax etc. details.
Reply to
Rob Morley
Loading thread data ...
On Sat, 16 Jun 2018 14:58:13 +0100, RobH declaimed the following:
If you are seeing files on the RPi, in /mnt/CCTV/PiZero, but are not seeing them on the NAS itself, the only conclusion I can draw is the NAS is NOT MOUNTED at /mnt/CCTV/PiZero
What does
df -a
report?
--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber
No, as I rebooted the PiZero and forgot I had to remount it again. There are 0 byte files on the NAS box bot no files on the Pizero machine. So to me it is like that the line
camera.start_recording(NASname)
is doing its job partly, and not writing to the sd card first. df -a //192.168.0.22/CCTV/PiZero/ 942639428 3187324 939452104 1% /mnt/CCTV/PiZero
And df -h
//192.168.0.22/CCTV/PiZero/ 899G 3.1G 896G 1% /mnt/CCTV/PiZero
Reply to
RobH
On Sat, 16 Jun 2018 15:23:25 +0100, RobH declaimed the following:
Which is the same permission error that the shutil.copyfile() was producing. This tells me that there is nothing wrong with the script itself. The problem appears to be on the NAS side -- since it IS accepting operations that provide a file name, but then refuses to accept the actual file data.
Restore the script to the version using RAMname for the capture, and with the .copyfile() back in place. When it dies do the following and cut&paste the results into a message:
ls -l /run/shm
cp /run/shm/*.h264 /mnt/CCTV/PiZero
rm -f /run/shm/*.h264
{Note: the last line is going to clean out old files from /run/shm -- cp & rm together produce the effect of
mv -f /run/shm/*.h264 /mnt/CCTV/PiZero }
--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber
On Sat, 16 Jun 2018 16:32:51 +0100, RobH declaimed the following:
The whole purpose of this exercise was to STOP writing to the SD card at all.
The version of the script using RAMname for the capture is supposed to store the file IN RAM, and then use copyfile() to move it from RAM to the NAS (followed by .unlink() to delete the copy left in RAM).
With the capture specified as NASname, the file should never be on the RPi physically (not in RAM, not in SD card), but is supposed to go directly to the NAS.
--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber
Depends on the user permissions the script is running at....
--
?It is hard to imagine a more stupid decision or more dangerous way of  
making decisions than by putting those decisions in the hands of people  
 Click to see the full signature
Reply to
The Natural Philosopher
I am assuming it is running as "pi" ...
Reply to
Andy Burns
I am not...:-)
--
Truth welcomes investigation because truth knows investigation will lead  
to converts. It is deception that uses all the other techniques.
Reply to
The Natural Philosopher
pi@raspberrypi:~/Downloads $ python intruder.py Traceback (most recent call last): File "intruder.py", line 40, in 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-06-16_19.57.21.h264'
pi@raspberrypi:~/Downloads $ df -h Filesystem Size Used Avail Use% Mounted on /dev/root 15G 4.3G 9.7G 31% / devtmpfs 182M 0 182M 0% /dev tmpfs 186M 13M 174M 7% /dev/shm tmpfs 186M 2.8M 183M 2% /run tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 186M 0 186M 0% /sys/fs/cgroup /dev/mmcblk0p1 42M 21M 21M 51% /boot tmpfs 38M 0 38M 0% /run/user/1000 //192.168.0.22/CCTV/PiZero/ 899G 3.1G 896G 1% /mnt/CCTV/PiZero
I have edited some of the information out of this: pi@raspberrypi:~/Downloads $ df -a Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 15205520 4456740 10068272 31% / devtmpfs 185484 0 185484 0% /dev sysfs 0 0 0 - /sys proc 0 0 0 - /proc tmpfs 189780 12300 177480 7% /dev/shm devpts 0 0 0 - /dev/pts tmpfs 189780 2840 186940 2% /run tmpfs 5120 4 5116 1% /run/lock tmpfs 189780 0 189780 0% /sys/fs //192.168.0.22/CCTV/PiZero/ 942639428 3187324 939452104 1% /mnt/CCTV/PiZero
pi@raspberrypi:~ $ ls -l /run/shm lrwxrwxrwx 1 root root 8 Jun 16 19:34 /run/shm -> /dev/shm
pi@raspberrypi:~ $ rm -f /run/shm/*.h264
Now here earlier it was running and albeit very slow, so I changed the ethernet connection from 100mBs to a1 Gb connection, and left it running
When I came back about 1 hour or so later the connection was lost. I rectified that by a reboot and checking the cable connections.
pi@raspberrypi:~/Downloads $ cp /run/shm/*.h264 /mnt/CCTV/PiZero cp: cannot create regular file '/mnt/CCTV/PiZero/2018-06-16_19.57.21.h264': Permission denied
pi@raspberrypi:~ $ rm -f /run/shm/*.h264 pi@raspberrypi:~ $
pi@raspberrypi:~/Downloads $ mv -f /run/shm/*.h264 /mnt/CCTV/PiZero mv: preserving times for '/mnt/CCTV/PiZero/2018-06-16_19.57.21.h264': Operation not permitted mv: preserving permissions for ?/mnt/CCTV/PiZero/2018-06-16_19.57.21.h264?: Input/output error
Reply to
RobH
Yes it is AFAIK
Reply to
RobH
Ignore the above as it is corrected below
After the permission denied again I went to my NAS box and changed the permissions for a windows share, as it was previously set for a Unix share.
Now pi@raspberrypi:~/Downloads $ cp /run/shm/*.h264 /mnt/CCTV/PiZero cp: cannot stat '/run/shm/*.h264': No such file or directory
Reply to
RobH
pi@raspberrypi:~/Downloads $ ls -l total 4 -rw-rw-rw- 1 pi pi 1117 Jun 16 16:53 intruder.py
Reply to
RobH
On Sat, 16 Jun 2018 20:25:23 +0100, RobH declaimed the following:
Well, if you either rebooted or ran that "rm" command, there would not be any files in RAM to be copied.
--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber
In article (Dans l'article) , mm0fmf
Using the command "id" would help:
DESCRIPTION The id utility displays the user and group names and numeric IDs, of the calling process, to the standard output. If the real and effective IDs are different, both are displayed, otherwise only the real ID is displayed.
--
Jean-Pierre Kuypers
Reply to
Jean-Pierre Kuypers
Like this, you mean?
pi@raspberrypi:~ $ id uid=1000(pi) gid=1000(pi) groups=1000(pi),4(adm),20(dialout),24(cdrom),27(sudo),29(audio),44(video),46(plugdev),60(games),100(users),101(input),108(netdev),997(gpio),998(i2c),999(spi)
Reply to
RobH
Apologies for late reply as I have been away for a week on holiday.
Yes that is what I did actually, as something happened , can't recall what exactly, but maybe a lock up or not running???
All the directories on the Pi Zero, permissions are set to 775, and owned by pi:pi
It seems that the permission problem is with writing the actual file, and not access to the NAS box.
What would be the next thing I should do
Reply to
RobH
On Sat, 23 Jun 2018 18:23:21 +0100, RobH declaimed the following:
Not having any NAS myself -- I'm out of my realm... Everything that follows is hypothetical.
If the NAS is capable of NFS besides CIFS/SMB (based on
formatting link
CIFS itself is considered obsolete... but other sites suggest that one install cifs-utils rather than smbfs
formatting link
) -- defining the share as NFS /on the NAS/ and changing the mount command(s) on the RPi to mount as nfs instead of cifs might improve the behavior.
--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber
Ok, I was getting permission denied with everything on the /mnt/CCTV/PiZero folder.
I removed all the existing files from the PiZero /mnt/CCTV/Pizero folder as they were all write protected, and had to reboot for the folder to show 0 files.
When I do ls -l I get total 4 drwxrwxrwxrwx 2 pi:pi 4096 June 24 18.47 PiZero
Then because of a reboot, I have to: pi@raspberrypi:~ $ sudo mount -t cifs -o username=root,password=2Sm4k5 //192.168.0.22/CCTV/PiZero/ /mnt/CCTV/PiZero
And now:
pi@raspberrypi:/mnt/CCTV $ ls -l total 0 drwxrwxr-x 2 root nogroup 0 Jun 24 18:55 PiZero
When I try to remove it: pi@raspberrypi:/mnt/CCTV $ sudo rm -r PiZero rm: cannot remove 'PiZero': Device or resource busy pi@raspberrypi:/mnt/CCTV $
So for some reason as soon as the PIZero directory is mounted, it becomes owned by root, as above with sudo mount.
If I remove -o I get:
pi@raspberrypi:~ $ mount -t cifs -o username=root,password=2Sm4k5 //192.168.0.22/CCTV/PiZero/ /mnt/CCTV/PiZero mount: only root can use "--options" option pi@raspberrypi:~ $ mount -t cifs username=root,password=2Sm4k5 //192.168.0.22/CCTV/PiZero/ /mnt/CCTV/PiZero mount: only root can use "--types" option
Now I am between the devil and the deep blue sea
Before I mount the PiZero directory it is owned by pi:pi, but after I mount the PiZero directory it is owned by root
I have also tried echo "hello" > /mnt/CCTV/test.txt , but nothing is created on the said directory, although the file is created on the actual PiZero CCTV directory
pi@raspberrypi:~ $ cd /mnt/CCTV pi@raspberrypi:/mnt/CCTV $ ls PiZero test.txt pi@raspberrypi:/mnt/CCTV $
Reply to
RobH
if you did "ls -la" you'd probably have found that . and .. were two of the mystery three directory entries.
**** = oops
can you not put a suitable entry in /etc/fstab, so that PiZero gets automatically mounted, with consistent rights?
try unmounting it first (or instead) "umount /mnt/CCTV/PiZero"
nothing on the Pi, or nothing on the NAS?
Reply to
Andy Burns

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.