error opening events folder

[dws]

while experimenting running ZM with other operating systems I have run across this error occasionally. I think it was a path and permissions problem. Somehow this was related to an event Export function failure where ZM could not write to the /var/cache/zoneminder/temp folder. Corrupting the path creations for the symlink. I will have to replicate it to remember what I did to fix it.

xxx@yyyy:/var/cache$ ls -la
total 92
...
drwxr-xr-x 5 www-data www-data 4096 Dec 22 17:27 zoneminder
xxx@yyyy:/var/cache$ cd zoneminder
xxx@yyyy:/var/cache/zoneminder$ ls -la
total 20
drwxr-xr-x 5 www-data www-data 4096 Dec 22 17:27 .
drwxr-xr-x 21 root root 4096 Dec 18 11:14 ..
drwxr-xr-x 10 www-data www-data 4096 Jan 18 12:33 events
drwxr-xr-x 2 www-data www-data 4096 May 9 2017 images
drwxr-xr-x 8 www-data www-data 4096 Jan 18 11:24 temp
xxx@yyyy:/var/cache/zoneminder$ cd temp
xxx@yyyy:/var/cache/zoneminder/temp$ ls -la
total 32
drwxr-xr-x 8 www-data www-data 4096 Jan 18 11:24 .
drwxr-xr-x 5 www-data www-data 4096 Dec 22 17:27 ..
drwxr-xr-x 2 www-data www-data 4096 Jan 18 12:02 zmswap-m1
drwxr-xr-x 2 www-data www-data 4096 Jan 16 12:05 zmswap-m3
drwxr-xr-x 3 www-data www-data 4096 Jan 18 13:10 zmswap-m4
drwxr-xr-x 2 www-data www-data 4096 Jan 18 11:25 zmswap-m5
drwxr-xr-x 4 www-data www-data 4096 Jan 18 13:11 zmswap-m7
drwxr-xr-x 3 www-data www-data 4096 Jan 18 13:10 zmswap-m8
xxx@yyyy:/var/cache/zoneminder/temp$


Permissions and ownership seem good, here.

I still think it has something to do with zoneminder attempting to traverse the directory structure via symlink rather than going directly to the monitor number directory, but, again, I could be incorrect.

[bbunge]

Again... Let me make this clear...

I.
DO.
NOT.
HAVE.
AN.
EXTERNAL.
DRIVE.

These errors are occurring on the internal drive(s) in the machine.

All the drives are formatted EXT4.

The errors in question seems to be Zoneminder not being able to find a file that actually does exist, and it is attempting to find that file through a symlink.

External, internal secondary, second drive...all the same. You have the images on another drive from where the OS is installed. Great that it is EXT4...but...how do you mount it? Are you sure it is mounted before Zoneminder starts? Did you use the systemd mount? Did you move the events and images directories to the "other" drive? I have used a second drive on Ubuntu 16.04 several times and have not experienced the issues you report. Might be worth your time to reinstall your system afresh...
Don't try too hard but use the easy install instructions in the WIKI. May I recommend Mariadb server with innodb_file_per_table turned on...

[dws]

The four drives in this system were created and formatted at the time of the OS install. They are part of the original system, and not add-ins.
I haven't moved any databases, migrated any data, or moved anything since system install or since zoneminder install.
The only "drive" that has been added since install was the google drive associated with my work account, via google-drive-ocamlfuse, and that "drive" isn't referenced anywhere in Zoneminder, or used by zoneminder.

Code: Select all

$ df -m
Filesystem             1M-blocks   Used Available Use% Mounted on
udev                        3969      0      3969   0% /dev
tmpfs                        798     82       717  11% /run
/dev/sdc3                 118383   1136    111211   2% /
/dev/sdb1                 938772   5180    885883   1% /usr
tmpfs                       3989   3428       561  86% /dev/shm
tmpfs                          5      1         5   1% /run/lock
tmpfs                       3989      0      3989   0% /sys/fs/cgroup
/dev/sdd1                 234603 209218     13446  94% /var
/dev/sda1                 234603    700    221964   1% /home
cgmfs                          1      0         1   0% /run/cgmanager/fs
tmpfs                        798      1       798   1% /run/user/112
tmpfs                        798      0       798   0% /run/user/1000
/home/xxx/.Private        234603    700    221964   1% /home/xxx
google-drive-ocamlfuse     15360    890     14471   6% /home/xxx/googledrive

So, can we please get past this "external/second drive" stuff and get to the root of the actual problem?

[rockedge]

looking at my notes the issue seemed to be a time stamp problem. My problem was the time on the mysql/mariadb was different then the system, apache2 and PHP time. This is important because the paths for the events (export, video creation) are built using the time the event is originally alarmed. So a path gets made that does not really exist. When looking at the events folder the images are there but ZM can't find it. I fixed it by stopping ZM then stopping the mysql server. I restarted both and the export worked again perfectly. So somewhere in this is your observation? Go check that the time is synced across the mysql and apache server and PHP and the system clock. Maybe?? give me a heads up if this is your problem..... I hope this helps.

[mikb]

If you're heading down that route -- don't just check the time, check the time ZONES being used are correct too!

An unexpected translation between UTC/Local/GMT/BST could really upset things

[bbunge]

The four drives in this system were created and formatted at the time of the OS install. They are part of the original system, and not add-ins.
I haven't moved any databases, migrated any data, or moved anything since system install or since zoneminder install.
The only "drive" that has been added since install was the google drive associated with my work account, via google-drive-ocamlfuse, and that "drive" isn't referenced anywhere in Zoneminder, or used by zoneminder.

Code: Select all

$ df -m
Filesystem             1M-blocks   Used Available Use% Mounted on
udev                        3969      0      3969   0% /dev
tmpfs                        798     82       717  11% /run
/dev/sdc3                 118383   1136    111211   2% /
/dev/sdb1                 938772   5180    885883   1% /usr
tmpfs                       3989   3428       561  86% /dev/shm
tmpfs                          5      1         5   1% /run/lock
tmpfs                       3989      0      3989   0% /sys/fs/cgroup
/dev/sdd1                 234603 209218     13446  94% /var
/dev/sda1                 234603    700    221964   1% /home
cgmfs                          1      0         1   0% /run/cgmanager/fs
tmpfs                        798      1       798   1% /run/user/112
tmpfs                        798      0       798   0% /run/user/1000
/home/xxx/.Private        234603    700    221964   1% /home/xxx
google-drive-ocamlfuse     15360    890     14471   6% /home/xxx/googledrive

So, can we please get past this "external/second drive" stuff and get to the root of the actual problem?

Well you did not say the drives were set up at system install. I would bet that 99% of the people who complain about using a second drive add that drive after OS install.

Looking at your df:
You are about out of shared memory (/drv/shm) which can cause problems with Zoneminder
Your /var is pretty full so the Zoneminder Events and Images folders under /var/cache/zomeninder may be full
With multiple drives the purge when full may not work right so purge on time may be best.

Other guys mentioned time settings. While I do not know if your problem can be caused buy time it may be a good idea to double check the time zone settings in your PHP.

[dws]

looking at my notes the issue seemed to be a time stamp problem. My problem was the time on the mysql/mariadb was different then the system, apache2 and PHP time. This is important because the paths for the events (export, video creation) are built using the time the event is originally alarmed. So a path gets made that does not really exist. When looking at the events folder the images are there but ZM can't find it. I fixed it by stopping ZM then stopping the mysql server. I restarted both and the export worked again perfectly. So somewhere in this is your observation? Go check that the time is synced across the mysql and apache server and PHP and the system clock. Maybe?? give me a heads up if this is your problem..... I hope this helps.

Time zones were set the same, but a restart of mysql and zoneminder concurrently (within seconds of each other) seems to have, temporarily, "solved" the issue. I say temporarily because going back to view a cam a couple of hours later brings that same error up again... yes, the mysql database and the zoneminder are on the same machine.

I'll set a cron job to restart both ZM and mysql periodically, just to keep those errors from filling the logs.

Thanks, rockedge, for suggesting something that didn't involve operator error, and which actually did the job.

Like I said, the problem isn't quite "solved", but it's definitely manageable, now.

[rockedge]

sounds like we are getting to the root of the problem, some further research and we could have it. It is interesting that the problem reappears! Someplace at sometime the time must be be incorrectly set. I also experienced during the testing that the path to the event is incomplete. A portion of the path string was missing from the symlink path. Please check that the paths in your zm.conf and in the Options->Paths are OK and generally look over all the possible places that at some point is changing the time. I think we can solve this so you do not have to use some hack to work around it. I will fire up some of my older Puppy Linux / ZM installs to find one that still does this. If I remember, using a different web server, in this case Hiawatha instead of Apache exposed some of these quirks. ZoneMinder is like a symphony......lots of intruments working together....there is a lot of little things that can cause ZM to drift from working... to pulling ones hair out....

[rockedge]

here is something that may also be happening.... viewtopic.php?p=104182#p104182

[dws]

@rockedge
My initial suspicion was that it had something to do with the fact that clicking on the live view links from the ZM console makes ZM look for the poly files via the symlink rather than going to the monitor number, no matter whether you clicked the monitor number or the camera "nickname" on the left of the ZM console...
Why the time thing temporarily fixed the issue is beyond my grasp, but I do know that the files ZM is looking for ARE there at the time of its looking.
Perhaps ZM should be re-coded to go straight to the monitor number, rather than using the symlink to the name?
It's something to think about, anyway.

[Rapheal]

Very interesting I got this same error, but I did also export an event. I'm seeing after I tried to delete an event..

[schramma]

Hello forum,

i had the same problem with that error-message. My solution was to change the DIR_EVENTS -Path from "events" to "/usr/share/zoneminder/www/events", where it is placed on my debian-installation. That works for me. It may help you, too.