[SOLVED] Migration gone bad

Channels DVR Server
#1

I moved my server from a linux pc to a new synology with DSM7. On linux I had an external usb drive and had the basic dvr pointed to the root of the USB Drive.

My new settings point to the same place on the synology which is a share folder called /volumeUSB1/usbshare which is the root of the same USB disk.

I have a permissions issue. I have the system internal user channels given read/write permissions to that share.
But my recordings are failing with the following error.
Failed: open /volumeUSB1/usbshare/TV/name-of-shows.mpg:permission denied

I don't know what to

1 Like
#2

I pasted your text into chatGPT, and it looks reasonable to me, it said the following:

here are some suggestions that might help you troubleshoot the issue:

  1. Check the ownership and permissions of the folder and the file: Make sure that the user running the DVR has read/write permissions on both the folder and the file. You can do this by running the following commands in the terminal:

bash

cd /volumeUSB1/usbshare/TV/
ls -l name-of-shows.mpg


The output of the second command should show the owner, group, and permissions of the file. Make sure that the owner is the same as the user running the DVR and that the permissions allow read and write access.
* Check the mount options of the USB drive: Synology DSM7 uses a new kernel that might have different mount options than your Linux PC. Check the mount options of the USB drive by running the following command in the terminal:

bash

1. ```
mount | grep /volumeUSB1/usbshare

The output of this command should show the mount options of the USB drive. Make sure that the mount options allow read and write access.

  1. Check the DSM7 firewall settings: Synology DSM7 comes with a built-in firewall that might be blocking the DVR from accessing the USB drive. Check the firewall settings by going to Control Panel > Security > Firewall and make sure that the DVR is allowed to access the USB drive.

  2. Check the log files of the DVR: The DVR might be logging more detailed error messages that could help you diagnose the issue. Check the log files of the DVR by going to its settings or documentation and look for any error messages related to permissions or file access.

#3

I had some trouble with the 1st part of part 1.
I thought the "users running the DVR" was the Synology internal system user channels. I have verified that the share has been given R/W for that directory share.

the 2nd part of part 1 was easy.
fred@Synology-2:/$ mount | grep /volumeUSB1/usbshare
/dev/usb2p1 on /volumeUSB1/usbshare type ext4 (rw,relatime,nodelalloc,synoacl,data=ordered)
not sure what all of that means. I assume the rw means read/write but I'm no linux pro.

Then on to Step 2. The Synology firewall has not been enabled.

Now Step 3.
From the logs I see examples like
• 2023/03/13 20:00:00.004340 [DVR] Starting job 1678755600-14 Rock the Block on ch=[6104]
• 2023/03/13 20:00:02.027538 [TVE] stream timestamps: hgtv: start_at=2023-03-13T19:59:01-05:00 end_at=2023-03-13T19:59:30-05:00 live_delay=27.316533465s
• 2023/03/13 20:00:02.027687 [TNR] Opened connection to TVE-Spectrum for ch6104 HGTV
• 2023/03/13 20:00:02.027996 [TNR] Closed connection to TVE-Spectrum for ch6104 HGTV
• 2023/03/13 20:00:02.028007 [DVR] Error running job 1678755600-14 Rock the Block: open /volumeUSB1/usbshare/TV/Rock the Block/Rock the Block S04E02 Living Room FaceOff 2023-03-13-2000.mpg: permission denied

I still don't know what to do about it.
I don't see any missing permissions. I'm missing something somewhere.

#4

You probably need to change the permissions on each directory

1 Like
#5

krikey you mean giving the internal system user R/W on the share is not recursive?
Oh boy. Ok I'll try

#6

Wife is starting to twitch! yikes. Not good.

I can't find the system internal user "channels" anywhere except under the share permissions in the GUI. I tried to give the permissions at the External USB drive level but that user does not show up under system internal user.
I am not confident enough to use chmod properly to do this and I don't know how to specify that special channels users anyway.

I followed the instructions for migrating and use the restore DVR wizard. I gave the share the permissions for the special channels users. I'm pretty sure I followed the directions.

#7

against my better judgement. I have gone into file station and given Read, Write, and Execute to Owner, Group, and Others. I did this to every folder on the USB drive by checking the "Apply to this folder, sub-folders, and files"
I think that is 777. This is a closed private network so I'm not too afraid but that seems wrong to me.
I'll see if the errors go away now.
jeeze Louise

#8

I keepnhesring about ChatGPT. It can do network trouble shooting? If so, that's really cool.

#9

After updating USB drive's permissions to 777 recursively I thought I'd schedule a few shows this morning to see if this worked.
Every one has the exclamation mark and not saying it was inturupted.

Below are the log entries for one of these test recordings.

I ordered larger NAS drives that will be here in a few days. Hoping to do away with the external USB drive for the main DVR content storage. I'll keep it for my "other sources" storage.

DevOps:
Here are the logs. What the heck is going on here???

**
2023/03/15 08:25:03.488383 [DVR] Waiting 34m46.511620875s until next job 1678888790-ch6045 Ax Men
2023/03/15 08:59:50.001430 [DVR] Starting job 1678888790-ch6045 Ax Men on ch=[6045]
2023/03/15 08:59:52.022887 [DVR] Recording for job 1678888790-ch6045 from TVE-Spectrum ch6045 into "TV/Ax Men/Ax Men S08E08 2015-01-18 Teepee of Death 2023-03-15-0859.mpg" for 1h3m9.998486708s
2023/03/15 08:59:52.955602 [DVR] Refreshing metadata for Ax Men (186086)
2023/03/15 09:45:22.644898 [SNR] Buffer statistics for "TV/Ax Men/Ax Men S08E08 2015-01-18 Teepee of Death 2023-03-15-0859.mpg": buf=0% drop=0%
2023/03/15 09:45:23.055663 [MTS] Statistics for "TV/Ax Men/Ax Men S08E08 2015-01-18 Teepee of Death 2023-03-15-0859.mpg": skipped=0 unhandled_packets=0 discontinuity_detected=0 transport_errors=0 invalid_pts=0 invalid_dts=0 saw_pcr=true saw_pmt=true highest_pts=2739.838322
2023/03/15 09:45:23.059119 [ADS] Detected 8 commercial markers in file-2605: TV/Ax Men/Ax Men S08E08 2015-01-18 Teepee of Death 2023-03-15-0859.mpg
2023/03/15 09:45:23.460830 [DVR] Error running job 1678888790-ch6045 Ax Men: panic: runtime error: index out of range [0] with length 0
2023/03/15 09:45:26.658445 [DVR] Starting job 1678888790-ch6045 Ax Men on ch=[6045]
2023/03/15 09:45:29.908109 [DVR] Error running job 1678888790-ch6045 Ax Men: could not start stream on channels=[6045]: TVE: stat /volumeUSB1/usbshare/Streaming: no such file or directory
2023/03/15 09:45:32.500116 [DVR] Starting job 1678888790-ch6045 Ax Men on ch=[6045]
2023/03/15 09:45:32.500299 [DVR] Error running job 1678888790-ch6045 Ax Men: could not start stream on channels=[6045]: TVE: stat /volumeUSB1/usbshare/Streaming: no such file or directory
2023/03/15 09:45:37.248882 [DVR] Starting job 1678888790-ch6045 Ax Men on ch=[6045]
2023/03/15 09:45:37.249126 [DVR] Error running job 1678888790-ch6045 Ax Men: could not start stream on channels=[6045]: TVE: stat /volumeUSB1/usbshare/Streaming: no such file or directory
2023/03/15 09:45:45.707256 [DVR] Starting job 1678888790-ch6045 Ax Men on ch=[6045]
2023/03/15 09:45:45.707555 [DVR] Error running job 1678888790-ch6045 Ax Men: could not start stream on channels=[6045]: TVE: stat /volumeUSB1/usbshare/Streaming: no such file or directory
2023/03/15 09:46:02.172952 [DVR] Starting job 1678888790-ch6045 Ax Men on ch=[6045]
2023/03/15 09:46:03.173363 [DVR] Recording for job 1678888790-ch6045 from TVE-Spectrum ch6045 into "TV/Ax Men/Ax Men S08E08 2015-01-18 Teepee of Death 2023-03-15-0859.mpg" for 16m57.826955176s
2023/03/15 10:03:04.619314 [SNR] Buffer statistics for "TV/Ax Men/Ax Men S08E08 2015-01-18 Teepee of Death 2023-03-15-0859.mpg": buf=0% drop=0%
2023/03/15 10:03:04.878566 [MTS] Statistics for "TV/Ax Men/Ax Men S08E08 2015-01-18 Teepee of Death 2023-03-15-0859.mpg": skipped=0 unhandled_packets=0 discontinuity_detected=0 transport_errors=0 invalid_pts=0 invalid_dts=0 saw_pcr=true saw_pmt=true highest_pts=3812.290033
2023/03/15 10:03:04.878702 [DVR] Finished job 1678888790-ch6045 Ax Men
2023/03/15 10:03:05.488490 [DVR] Processing file-2605: TV/Ax Men/Ax Men S08E08 2015-01-18 Teepee of Death 2023-03-15-0859.mpg
2023/03/15 10:03:07.430459 [IDX] Generating video index for file-2605: TV/Ax Men/Ax Men S08E08 2015-01-18 Teepee of Death 2023-03-15-0859.mpg
**
#10

Does this directory exist? Did you set the permissions on it as well?

#11

yes it exists and yes I gave all folders on the USB Drive 777
Do you think this has something to do with the way Synology handles sharing on USB Drives?
As soon as you plug an ext4 drive into the port, the NAS shares it as usbshare1. When I browse to the path through the channels settings web interface using the DVR Database section, it shows up as /volumeUSB1/usbshare.
When I SSH into the NAS as administrator user. I can navigate to /volumeUSB1/usbshare

ls -l
drwxrwxrwx  33 1000 1000  4096 Mar 15 13:29 Database
drwxrwxrwx+  3 1000 1000  4096 Mar 15 13:29 @eaDir
drwxrwxrwx   4 1000 1000 32768 Mar 15 10:03 Images
drwxrwxrwx   5 1000 1000  4096 Feb 22 08:58 Imports
drwxrwxrwx   4 1000 1000  4096 Feb  9 15:25 Logs
drwxrwxrwx   2 1000 1000 16384 Feb 22 14:49 lost+found
drwxrwxrwx   2 1000 1000  4096 Feb 19 17:27 Movies
drwxrwxrwx  46 1000 1000  4096 Mar 15 10:03 Streaming
drwxrwxrwt   2 root root  4096 Jan 10 10:59 @tmp
drwxrwxrwx  57 1000 1000  4096 Mar 15 08:59 TV
#12

I'm going to move all of the data to the internal NAS drives and see if that changes anything.
I am suspicious about how Syn treats these external USB drives

#13

With what filesystem is the external drive formatted? I'm guessing ExFAT or FAT32.

Personally, I run into all kinds of problems with any flavor of FAT with Linux. I think it's because FAT doesn't support file ownership. So I'd get into the situation where the OS treats every directory and file on the drive as owned by "root" making them unwriteable by any other user (and typically you don't want to run the Channels DVR server as root).

1 Like
#14

FYI... If you see numbers in the user and group fields like you do in the above screen cap, then the files and dirs are probably owned by a user not known to the system. You might want to do a "chown -R " to change the ownership to whatever user is running the Channels DVR server process.

#15

it is ext4

#16

I moved all of the DVR content into the internal NAS drives and the problem went away instantly.
I'm not suggesting you cannot run external USB drives on Synology with Channels. I know for a fact that you can.
In my case. I had a MINT PC as my channels server and I stored everything on the external 6TB USB Drive. By "stored everything" I mean that in the channels settings web admin screen. Under the "basic setup" section. My path was set to the root of the USB drive which was formatted as EXT4.
With Synology DSM7 when I migrated according to the instructions. I backed up my DB and shut down the DVR on the MINT box and simply moved the USB drive to the port on the new Synology. This turned into a nightmare of permission and other problems.
AS SOON AS I moved the files to the internal NAS disks all of those problems went away.
So I ordered new NAS drives that are MUCH larger. :grin: And I reformatted that 6TB USB drive for a different purpose. All my new recordings have no issues at all.
Thanks everyone for the great suggestions.

#17

Just to be clear, ChatGPT does NOT actually troubleshoot, but instead uses it's vast data scraped from the internet to predict what the issues maybe.

This can be helpful intracking down issues of any sort.

but be warned!!! DO NOT blindly run any commands it may produce without knowing exactly what they do, especially if the command may make alterations to system or data!!!

But with background knowledge of such commands, it can be very helpful in tracking down issues.

I knew what the commands in my post about this do, and that they were safe to try.

ChatGPT is great, but it is a reflection of data across the internet, and sometimes can lead you astray.

#18

so just like stackoverflow!

stackoverflow banned chatGPT not so long ago

#19

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.