Advanced Search

Taking an educated guess, it could be a permission issue, using the link you provided and removing the filename gets a directory listing in a browser, 403 is there when trying to download, other files are accessible.
Hopefully Andy will become aware of this, one option might be to access either the mailing lists, I'm banned due to comments on the origins of Code of Conducts and implementor, or GitHub.

When trying to install the update for 2.9.5 on a Raspberry Pi, I receive a security error when attempting to fetch The error is:

Forbidden
You don't have permission to access this resource.
Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.

My guess is that it's trying to mount the nfs share before the wifi interface is up.
So you may have to look through dmesg to see when the nfs share is being mounted and when the wifi interface is being brought up.
Do you have any issues trying to mount the share after the wifi network is up ?

There may be a way to do it via systemd that waits for the wifi network to come up, I've got a couple of ones that turn off the power related stuff for wifi, but only after the interface is up. Might be able to use the same mechanism to mount the shares once that interface is up.

I'd suggest this isn't a issue related to the Raspberry Pi platform but any situation where an nfs or samba share is automounted and the required interface isn't up at that time.

Trying to get nfs between workstation and mill.
Posted here hoping the RPi developers may have a solution.

nfs server - workstation: hp desktop ubuntu 24.04.
nfs client - mill: RPi 4B 4GB LC 2.9.4.
 
wifi is working fine.
sftp between the stations without issue.

nfs works after a manual mount on the client.
Cannot get nfs to mount automatically at start up.

The /etc/fstab file is populated (to the best of my searching).
Tried a couple of web suggestions, but no solution yet.

Looked through the startup log:
    - "mount.nfs: Network is unreachable".

Tried several web suggestions, including increasing the wait time.

Did some searching on the Raspberry Forum without success.

When I issue a terminal command "mount' after starting LC, there is a response about an old version and to use "systemctl-daemon reload".
After reboot, entered 'systemctl-daemon reload', got 'command not found'.
Tried 'systemctl daemon-reload', accepted without success.

Any suggestions getting the mount at start-up ?

John.

On the bright side I figured out what my problem was. I had followed the documentation with recommended the preconfigured xpatria raspberry pi build and that did make getting everything up and running easy but, I didn't think to git clone the newer Remora developments since that image was released so I was running the older halcompiled remora-spi which I'm sure now was causing me issues. Now that I have pulled the most recent Remora version and compiled remora-spi again with halcompile like the docuementation says to do, although I noticed that in an earlier post it was mentioned that you no longer need the SPI_clk_div=32 after the loadrt remora-spi component in the HAL file but, mine wouldn't come out of estop until I added that back into the line. I also had a grounding issue and some EMI issues that collectively were causing my spindle to throw errors and after that and the correct version of firmware on the Octopus and most recent Remora branch then it looks like I'm good now.

If you try to connect remotely via VNC after logging in with your username from the console, you'll get a gray screen. You'll need to log out from console.