Updated router firmware, and now Channels can't see my network shares

I have a Netgear Nighthawk AC1900 R7000 router. It's worked perfect for years now. I also have Channels running on a Raspberry Pi 4b, using the Channels image Version
2022.0601.2221. and server Version
2024.09.10.2115

Everything worked fine until earlier today, when I upgraded the router firmware from version R7000-V1.0.11.136_10.2.120 to the latest version: R7000-V1.0.11.216_10.2.122.

Now, it can't see my network shares, and I get these errors:

[quote]× shares-Rnas.mount - Rnas Share
Loaded: loaded (/etc/systemd/system.control/shares-Rnas.mount; static)
Drop-In: /etc/systemd/system/shares-.mount.d
└─distro.conf
Active: failed (Result: exit-code) since Sat 2024-09-21 21:49:19 EDT; 2min 2s ago
TriggeredBy: ● shares-Rnas.automount
Where: /shares/Rnas
What: //192.168.1.1/S_Drive/

Sep 21 21:49:19 dvr-server systemd[1]: Mounting Rnas Share...
Sep 21 21:49:19 dvr-server mount[1870]: mount error(95): Operation not supported
Sep 21 21:49:19 dvr-server mount[1870]: Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
Sep 21 21:49:19 dvr-server systemd[1]: shares-Rnas.mount: Mount process exited, code=exited, status=32/n/a
Sep 21 21:49:19 dvr-server systemd[1]: shares-Rnas.mount: Failed with result 'exit-code'.
Sep 21 21:49:19 dvr-server systemd[1]: Failed to mount Rnas Share.[/quote]

And: [quote]× shares-Mynas.mount - Mynas Share
Loaded: loaded (/etc/systemd/system.control/shares-Mynas.mount; static)
Drop-In: /etc/systemd/system/shares-.mount.d
└─distro.conf
Active: failed (Result: timeout) since Sat 2024-09-21 21:52:17 EDT; 25min ago
TriggeredBy: ● shares-Mynas.automount
Where: /shares/Mynas
What: //192.168.1.4/WDTV_drive_0/

Sep 21 21:50:47 dvr-server systemd[1]: Mounting Mynas Share...
Sep 21 21:52:17 dvr-server mount[1884]: Failed to query password: Timer expired
Sep 21 21:52:17 dvr-server systemd[1]: shares-Mynas.mount: Mounting timed out. Terminating.
Sep 21 21:52:17 dvr-server systemd[1]: shares-Mynas.mount: Mount process exited, code=killed, status=15/TERM
Sep 21 21:52:17 dvr-server systemd[1]: shares-Mynas.mount: Failed with result 'timeout'.
Sep 21 21:52:17 dvr-server systemd[1]: shares-Mynas.mount: Unit process 1883 (mount.cifs) remains running after unit stopped.
Sep 21 21:52:17 dvr-server systemd[1]: shares-Mynas.mount: Unit process 1884 (systemd-ask-pas) remains running after unit stopped.
Sep 21 21:52:17 dvr-server systemd[1]: Failed to mount Mynas Share.[/quote]

They still work perfectly from my laptop, through Network Neighborhood (or whatever it's called in Windows 10)

Yes, the router was power-plug pulled reset after upgrading the firmware. Also, my laptop has NO issues seeing the network drives. Also, the Channels DVR was rebooted through the admin Settings page using the "Manage" button and choosing "Reboot".

The 'RNAS' drive is a 4TB WD drive plugged into the front READYSHARE port on the router. It's worked for years before this. The "Mynas" drive share is a 1TB drive hanging off an old WDTVLIVE box, at IP 192.168.1.4. It's also worked for years before this.

Any ideas?

Logs submitted: 6dee5a44-1c89-4452-ba24-1ec7ab7e5f10

Going to go with Stupid Simple, but are both of those shares still at the same IP address?
And shared (using Samba?) on the same Workgroup and using the same User name and Password?

Yes, to all those questions as far as I can tell. I made NO changes after updating the firmware, and every device on my network is pemanently mapped to IP addresses, so they can't move around automatically. The WDTVLIVE "Mynas" share is SMB1 since it's so old. I remember originally I had a bitch of a time figuring out how to map it.

I hear you, obviously the router firmware update made some changes.
Problem is that Release Notes on a lot of things (including Channels) don't mention all the changes made. No ideas then.

Nevermind, they still don't work right

Instead of relying on Channels to handle the mounting and mapping of the shares, have you considered mounting the shares in your fstab, and then under the Personal Media section choosing the local mount point?

If you need a primer on how to do that, Arch's wiki has a pretty comprehensive Samba page, including a section on configuring SMB mounts.

Have you checked the release notes for the firmware? SMB1 has mostly been deprecated due to security concerns and may have been removed as an option in the firmware.

It's the Raspberry pi Channels build image. I'm not sure it'll allow that since it has a built-in admin option to do that. I'll have to do some research, because I know next to nothing about Linux, and most of my pc skills are way out of date.

This is the release notes. I see nothing in particular that should have done this. If you click on the security fixes link, there's so many from who knows what releases, hard to tell which apply.

Enhancement:

  • Ending ReadyCLOUD service for WiFi routers.

Security Fixes:

Anybody have advice on a newer up to date router, that includes a port to plug in a USB drive, and gives it access over your local LAN through Samba? Though I'd much rather just fix this issue, and be done with it.

If you SSH in to the Pi, you will be root with full administrative privileges. This means you are free to create/modify system files, such as /etc/fstab.

(You just don't want to do too much mucking about, because the OS partition is rather small. Other users in the past ran into issues with Docker containers going a bit crazy and filling up the partition.)

Well, I haven't SSH'd into the Pi since I set it up. It no longer wants to allow me to do so from Windows 10, so I can't make any ROOT changes. I also can't access it with PUTTY.

Maybe I should just give up on using the Pi image completely, and put my server back on a Windows pc.

I now have even downgraded the router software back to the version before I did the upgrade, and from Channels, I can now access the drive connected to my WDTVLIVE again, but NOT the Readyshare drive connected directly to my router. It just won't mount it anymore.

It works from Network Neighborhood in Windows just fine.

Beats me, I really love Channels, but I don't want to have to constantly do all these updates and configurations just to keep it running.

I wouldn't use a router for shared storage. Just because you could, doesn't mean it's a good idea (as you found out). Could be they updated the router to use modern SMB v2 or v3 and disabled SMB v1 support.

Is this how your network looks? (excuse the crude drawing)
Capture

More or less, yes. The pc is wireless, but the rest is wired either through the few back of the router ports and/or a 1 gig switch. The 4TB WD Readyshare drive is connected to the router with a router USB port that's made for that purpose. It's worked fine like that for years.

Can you access the SMB share from another computer on the network?

If you ssh into the PI, can you access the SMB share from the command line?

Any reason you don't plug your USB drive directly into the PI?

If you are sharing the drive to other computers besides the PI, you could set up the sharing from your PI.

See my comments after each question above.

Possibly you don't have port 22222 configured for ssh. Try connecting on the default port with:
ssh root@dvr-server

@tmm1

I had both shares working again after rolling back the router software. Then stupidly, I checked to see in there was a newer RP server version, and found that there was. I then decided to upgrade the RP dvr server from 2022.0601.2221, to the last 2023.0108.2341.

Now, with the new server version, I can access the S_Drive hanging off my router, but now I can NOT access the WDTV_drive_0 hanging off my WDTVLIVE that's at address: 192.168.1.4 I could access before. NOTE: there's no Workgroup OR WDTVLIVE password that I'm aware of, and it was working perfectly before I upgraded to the latest RP server version. Something in that version broke it. Maybe it doesn't like the underscores in the name WDTV_drive_0 ?

Here is the error it gives me:

× shares-Mynas.mount - Mynas Share
Loaded: loaded (/etc/systemd/system.control/shares-Mynas.mount; static)
Drop-In: /etc/systemd/system/shares-.mount.d
└─distro.conf
Active: failed (Result: exit-code) since Tue 2024-09-24 08:56:17 EDT; 1min 19s ago
TriggeredBy: ● shares-Mynas.automount
Where: /shares/Mynas
What: //192.168.1.4/WDTV_drive_0/
CPU: 16ms

Sep 24 08:56:16 dvr-server systemd[1]: Mounting Mynas Share...
Sep 24 08:56:17 dvr-server mount[644]: Password for root@//192.168.1.4/WDTV_drive_0/:
Sep 24 08:56:17 dvr-server mount[643]: Retrying with upper case share name
Sep 24 08:56:17 dvr-server mount[643]: mount error(6): No such device or address
Sep 24 08:56:17 dvr-server mount[643]: Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
Sep 24 08:56:17 dvr-server systemd[1]: shares-Mynas.mount: Mount process exited, code=exited, status=32/n/a
Sep 24 08:56:17 dvr-server systemd[1]: shares-Mynas.mount: Failed with result 'exit-code'.
Sep 24 08:56:17 dvr-server systemd[1]: Failed to mount Mynas Share.

It comes up with all 3 shares (drives) hanging off the WDTVLIVE, so not sure why it then won't actually mount it.

Which other options are available here?
Have you tried the other ones (I don't use it, but I'm assuming SMBv2, SMBv3, etc.)

The others are SMB2 & SMB3. However, the WDTVLIVE is an older device, and is only SMB1. It can't find it at all if I try the other ones. While trying to map it through that Add SMB Share widget, it clearly finds the WDTVLIVE and brings up the 3 shares hanging from it. It then asks me to Nickname it, which I do, and maps it in the "Shares" list on the Admin page, but will no longer actually connect to it. It gives the error above.

It's almost as if the name isn't right or something. But I can assure you, it IS, and used to work fine for years. It only now is doing this again after I updated the Pi's server version to the last one, 2023.0108.2341.

Maybe I should just give up on all this, and add another USB drive directly to the Pi itself. It's just that the WDTVLIVE sits permanently ON and connected to my network for many years now, acts as a media server, has tons of my videos on it collected over 12 years, worked previously with Channels, so there was NEVER a need to change it