Failed to mount /mnt/archive

[the-scott-davis]

I followed the one page setup, and also did a manual setup just to see if there were any differences, but essentially, the TeslaCam recordings work well, but I am not syncing any videos to my archive folder.

The logs don't have much information, but i am seeing the following in the logs:

Thu 16 May 21:07:07 BST 2019: Failed to mount /mnt/archive.
Thu 16 May 21:07:07 BST 2019: Attempts exhausted.
Thu 16 May 21:07:07 BST 2019: cam archive not mounted

Does this indicate that it cannot connect to my shared network folder? Or what exactly is /mnt/archive and how can I further debug this?

Right now, my device is properly storing RecentClips and SavedClips, and disconnects when i get within wifi range, as expected, but nothing is syncing over to my network share.

Incase it helps, the archive folder is on a Mac. I am able to see /mnt/archive when ssh'd in, there are no failes in it or /mnt/cam, but i do see the directories.

[the-scott-davis]

For more context, I reset everything and did a headless setup, and still have the same issue.

[marcone]

/mnt/archive is where it will mount the network share. Note that this does need to be a "Windows" share (i.e. using cifs/samba protocol) with the default setup.
If you run grep archive /etc/fstab on the Pi it will show you which server it is trying to use and the name of the share and path on that server. It should say something like:

//fileserver/Video/Tesla /mnt/archive cifs vers=3.0,credentials=/root/.teslaCamArchiveCredentials,iocharset=utf8,file_mode=0777,dir_mode=0777 0

In this example "fileserver" is the name of the server, "Video" is the name of the share on that server, and "Tesla" is the name of the folder on that share that the files will be copied to.
Also make sure that the file /root/.teslaCamArchiveCredentials contains the correct username and password for that server, or just:

username=
password=

if it's not authenticated (guest mode).

Finally, note that it will only backup the stuff under SavedClips, not RecentClips.

[the-scott-davis]

So @marcone if it’s a windows share, and I’m on a Mac... that seems to be my problem I suppose. Are there any other options for me? Or do I need to fork and create my own sync process for Mac shares?

[marcone]

I don't know enough about Mac OS to answer that. I know Mac OS can access Windows file shares, but does Mac OS not have the ability to create a network share that can be accessed by Windows machines?

[the-scott-davis]

I don't know enough about Mac OS to answer that. I know Mac OS can access Windows file shares, but does Mac OS not have the ability to create a network share that can be accessed by Windows machines?

Ok, thanks. Let me do some debugging, and maybe some tweaks and I'll reply here with a solution.

[the-scott-davis]

/mnt/archive is where it will mount the network share. Note that this does need to be a "Windows" share (i.e. using cifs/samba protocol) with the default setup.
If you run grep archive /etc/fstab on the Pi it will show you which server it is trying to use and the name of the share and path on that server. It should say something like:

//fileserver/Video/Tesla /mnt/archive cifs vers=3.0,credentials=/root/.teslaCamArchiveCredentials,iocharset=utf8,file_mode=0777,dir_mode=0777 0

In this example "fileserver" is the name of the server, "Video" is the name of the share on that server, and "Tesla" is the name of the folder on that share that the files will be copied to.
Also make sure that the file /root/.teslaCamArchiveCredentials contains the correct username and password for that server, or just:

username=
password=

if it's not authenticated (guest mode).

Finally, note that it will only backup the stuff under SavedClips, not RecentClips.

Following up on this. Keep in mind, I am using a Mac share, and per your statements above, it looks like it may need to be a Windows share. Nonetheless, running:

grep archive /etc/fstab

Returns nothing.

In addition, despite a successful installation from the headless installation, the /root/.teslaCamArchiveCredentials path is just empty.... the file doesn't exist.

I am thinking about modifying the script to scp or rsync the files over to my Mac share once connected. Will keep you posted.

[the-scott-davis]

I saw you had some rsync support in the repo already, so I added the ARCHIVE_SYSTEM=rsync and configured the appropriate params for rsync.

I ran the setup script again as well, for good measure, and verified that it completed successfully. RSYNC config is still in the teslauser_setup_variables.conf file but it looks like it's still trying to mount /mnt/archive and do the regular process.

Not a whole lot of logs to go off of tho, so I'm not really sure what's going on.

@marcone any advice on the rsync setup? I'd be fine with rsync as the solution, just can't seem to get it working.

[marcone]

fstab and the credentials file probably didn't get updated/created because the setup script couldn't connect to your server during setup. There's probably something about that in the setup log.
Can't help you with rsync setup, sorry. I've never used it, it's just something inherited from the upstream project.
For what it's worth: a Mac can share to a Windows machine, you just need to tell it to use the SMB protocol instead of the AFP protocol. This is in System Preferences > Sharing > File Sharing > Options

[the-scott-davis]

For what it's worth: a Mac can share to a Windows machine, you just need to tell it to use the SMB protocol instead of the AFP protocol. This is in System Preferences > Sharing > File Sharing > Options

Yeah, I have it setup as an SMB share already. I even tried installing smbmount and smbclient and manually mount the drive to see if i could get that working as a temporary solution. No luck their either. Still playing around with different options, but nothing is working unfortunately.

[marcone]

If you figure it out let me know, so I can add to the documentation if needed.

[Vipercat]

@marcone, I did a full refresh of my setup based on the Buster image and all went well. The PI has been running al night and when I check the archiveloop.log I see all operating successfully. Until I stepped in the car this afternoon (at 14:15, see log below) and I noticed a dashcam icon with the grey x. I started driving in the assumption that it might be in this state due to the car being connected to WiFi and the mount to archive instead of the car. Unfortunately the grey x stayed and so I disconnected and reconnected the data-USB. I also have a power-USB so the PI kept running. During the rest of the drive the icon changed in the red dot, so all okay. I saved a recording by pressing the icon and this also operated as intended. Then when I arrived home again (at 14:28) the archiveloop.log reported 'Archive reachable' and saved the recording I forced by pressing the icon. Since then all seems operating as it should. Will check in the morning what the icon status is, but any idea why this error occurred? Also I noticed not having the teslaCamArchiveCredentials file in /root/, but despite that the PI was able to mount the archive. Expected this would have failed, due to the file missing but this was not the case. Any idea why? Of course the credentials were in the teslausb_setup_variables.conf file required for the installation.