0

Up until May 2021, motion was working successfully on my Raspberry Pi 4. After May 2021, when motion is running and my web camera is enabled, as soon as it detects any motion, the camera disables itself.

I've reviewed the following related questions before posting, but they did not offer any solution:

What permissions does Motion require to write to specific directory?

Motion ffmpeg_open: url_fopen - error opening file (check access rights to target directory)

I checked /var/log/motion/motion.log and it reports the following:

[1:ml1] [ERR] [ALL] [Nov 23 11:05:46] myfopen: Error opening file /media/samba_disk/motion/01-20211123110546-snapshot.jpg with mode w: Permission denied
[1:ml1] [ERR] [ALL] [Nov 23 11:05:46] put_picture: Can't write picture to file /media/samba_disk/motion/01-20211123110546-snapshot.jpg - check access rights to target directory
Thread is going to finish due to this fatal error: Permission denied
[1:ml1] [ERR] [EVT] [Nov 23 11:05:46] event_image_snapshot: Could not create symbolic link [01-20211123110546-snapshot.jpg]: Permission denied
[1:ml1] [NTC] [ALL] [Nov 23 11:05:46] motion_loop: Thread exiting
[1:ml1] [NTC] [STR] [Nov 23 11:05:46] stream_stop: Closing motion-stream listen socket & active motion-stream sockets
[1:ml1] [NTC] [STR] [Nov 23 11:05:46] stream_stop: Closed motion-stream listen socket & active motion-stream sockets
[1:ml1] [NTC] [VID] [Nov 23 11:05:46] vid_close: Cleaning up V4L2 device
[1:ml1] [NTC] [VID] [Nov 23 11:05:46] v4l2_cleanup: Closing video device /dev/video0

To confirm, the target directory in /etc/motion/motion.conf:

more /etc/motion/motion.conf | grep target_dir
target_dir /media/samba_disk/motion

Checking the permissions of the target directory, the owner and group is motion and permissions are 777:

ls -la /media/samba_disk/
drwxrwxrwx 51 motion              motion              12288 Nov 14 14:58 motion

My local user is also a member of the motion group:

$ groups
tv adm dialout cdrom sudo audio video plugdev users input netdev debian-transmission motion gpio i2c spi

I also made sure that the disk of the target directory is mounted and has free space:

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       916G  340G  531G  40% /media/samba_disk

Everything appears to be set correctly for files to be written to motion's target directory. So why do I still receive write permission errors?

jimjamz
  • 73
  • 2
  • 8
  • You referenced two related questions, and said, "...they did not offer any solution". Does that mean you tried the accepted answer, and that it did not work for you? If so - what was your result when you ran ps aux | grep -v grep | grep motion? – Seamus Dec 08 '21 at 16:54
  • @Seamus - I followed the provided answers for both previous questions, but still encountered write permission issues. The psaux command returns motion 765 0.5 0.2 178200 19604 ? Sl 07:24 0:18 /usr/bin/motion – jimjamz Dec 21 '21 at 08:28
  • Have you reviewed my answer? Do either 1. or 2. seem to hold any hope for you? From what I've read here, the most likely cause of this seems to be that something slipped out-of-sync. But unless someone who has had your identical experience and resolved it finds your question & answers it, I wonder about your chances for resolution here - It's been almost 2 weeks now. – Seamus Dec 21 '21 at 08:40

1 Answers1

1

From your description, it seems a distinct possibility that something changed in May, 2021. That something could have been in your RPi configuration (perhaps as the result of an update), or it could have been that motion was changed.

You didn't indicate when you last performed an apt update and apt upgrade. If you've not done that recently, it would be a good idea to do that now - perhaps your issue has already been resolved?

The errors you cited in your question certainly look like permissions issues, but I would caution you against making permission changes willy-nilly as unintended consequences are always lurking in the shadows.

If the update & upgrade suggestion above didn't resolve your issue, two alternatives that are more likely than permission-fiddling to lead to a stable solution are:

1. Use the support resources provided by the motion project

motion seems to be a well-resourced, active project supporting a number of platforms. They maintain a mailing list, and it's quite likely that you're not the only RPi user who's encountered the issue you've described. motion also maintains a repo on GitHub with useful resources.

2. Remove and re-install motion

If you aren't inclined to mailing lists, or just impatient to move ahead, it's easy enough to remove the motion package, and re-install it. If you elect this approach, be sure to run update & upgrade before you begin:

sudo apt update
sudo apt upgrade

Having done that, you can remove your current version of motion as follows:

sudo apt-get purge motion

The purge option will remove motion as well as any configuration files it set up (ref man apt). It might also be a good idea to set aside your samba-based target_dir and use a local target_dir (e.g. /home/pi/motion_target) to eliminate the variable of samba issues.

It won't hurt to run update & upgrade after the purge.

Finally, re-install motion & edit its config file as required:

sudo apt-get install motion
Seamus
  • 21,900
  • 3
  • 33
  • 70
  • Apologies for the delay in response but I was away from the device. Before reading your answer, I had already tried your provided solutions, as this is a common diagnostic technique I also adopt. apt update and apt upgrade is ran daily. I also removed motion, including the config files with an apt purge, updated, upgraded and re-installed. The write permission issue persists. – jimjamz Dec 21 '21 at 08:33
  • @jimjamz: :) OK - so much for my theory! :) Unfortunately, I'm not a motion user. I'd hoped I could help despite that, but it seems I've failed. Re-reading your question just now though, something has occurred to me: Does user motion have write permissions to your Samba server? – Seamus Dec 21 '21 at 08:47
  • I have my suspicions that samba may be somehow involved in this, and particularly the file masking when files are created. I have no proof of this, of course, but I have my concerns. What I intend to do is repeat the whole removal/re-install process again, but with a different target directory this time. – jimjamz Dec 24 '21 at 18:03
  • @jimjamz: That sounds like a reasonable plan, but maybe try this first: become user motion, then try to mount your Samba drive. – Seamus Dec 24 '21 at 19:57
  • The user motion wouldn't be able to mount the Samba drive, just as my regular user wouldn't. It would require root setuid or sudo. – jimjamz Dec 28 '21 at 18:59
  • @jimjamz: Apologies - I said mount when I meant connect; as in su motion, and then try to connect to the server with (e.g.) smbclient. My point being: You can test your Samba server to see if it is allowing the motion user to connect outside of the motion app - it's just a troubleshooting approach to lern where the issue is. – Seamus Dec 29 '21 at 00:42
  • Hi @Seamus - Thanks for continuing with the suggestions. su motion requires a password for that user, which I do not know. I have tried those mentioned in /etc/motion/motion.conf such as motion, password and the authentication password, canyouseeme to no avail. Furthermore, I'm not sure if a "full" motion user is created during the motion installation and configuration. – jimjamz Dec 31 '21 at 13:46
  • I created a new directory on my samba disk with 777 permissions, and ownership and group access to motion; similar to the previously used directory, updating target_dir in /etc/motion/motion.conf. I got the same errors. I then changed target_dir to the default specified directory, /var/lib/motion/. This resolved the write permission issues. I also noticed that the /var/lib/motion/ directory has motion:adm ownership, and not motion:motion. I mimicked the ownership, access and permissions on my samba disk directory, but still receiving write permission errors. – jimjamz Dec 31 '21 at 13:55
  • @jimjamz: Samba has two sets of permissions: One handled by Samba itself - the one you use to authenticate yourself when you connect via Samba, the other are your local file system permissions. Check your local file system permissions using ls -l & make sure your Linux permissions accommodate the motion user. Other than that, have you tried the resources provided by the motion project in # 1. above? Surely this isn't the first time this has occurred?? – Seamus Dec 31 '21 at 20:09
  • @jimjamz: I've just found this page detailing Configuration on motion's GitHub page. After looking at the size and organization of this file, I wonder why it has to be this convoluted. I'm beginning to wonder if the project has suffered a loss of all their experienced team members. One becomes used to dealing with arcane issues in Linux - but I've never seen anything quite like this. Have you tried using a directory on your SD card for motion? – Seamus Dec 31 '21 at 20:24
  • Hi @Seamus. Yes, I've attempted using a directory on the SD card. As mentioned, if I use the target_dir that is (or used to be) specified as default, /var/lib/motion, the images are written successfully to the directory. I tried using symlinking /var/lib/motion with /media/samba_disk/motion, and leaving /var/lib/motion as the target_dir, but the permissions issue returned. I had to set up a cron job to move the files. – jimjamz Jan 08 '22 at 08:55
  • @jimjamz: That's odd that a cron job can do it, but you can't do it from your interactive shell (bash?). user pi cron jobs run under user pi's privileges, so that's worth investigating. – Seamus Jan 08 '22 at 09:54
  • I can move the files from /var/lib/motion to /media/samba_disk/motion/ on the command line also. I choose to do this using a cron job so the task doesn't become repetitive (if motion continuously captures). But this is clearly a workaround. I would be interested to find the root cause of why motion no longer write permissions to a directory other than those under root (/). When I have time to think of other possible solutions, I will try again. – jimjamz Jan 09 '22 at 13:53