MiSTer FPGA Forum

losth1ghway wrote: ↑Sun Oct 29, 2023 10:23 am

today i noticed, after mounting all folders under games/, the update_all script is failing due to a permissions error on /media/fat/games/Apple-I.
it update runs fine if i unmount the shares (via nfs_unmount.sh).

it seems like permissions for Apple-I is set the same as everything else under games as far as I can tell.

Code: Select all

drwxr-xr-x  4 dbus dbus   7 Mar  7  2022  AO486
drwxr-xr-x  2 dbus dbus   2 Mar  7  2022  APOGEE
drwxr-xr-x  2 dbus dbus   2 Feb 20  2020  Apple-I
drwxr-xr-x  3 dbus dbus   4 Mar  7  2022  Apple-II
drwxr-xr-x  2 dbus dbus   2 Mar  7  2022  AQUARIUS

What about the permissions on the server's end? Might be worth a quick chown / chmod.

If you have all of games/ coming from NFS, then the mount doesn't treat anything below games any different. It's server-side then: permissions or ownership on the server may be wrong or your NAS is mapping the root user to something weird. Maybe you even run into case sensitivity issues here, not sure, but you might get a wrong error message in that case.. happened to me with Neo Geo at one point.

I'm not sure why but an update in the last week broke my nfs_mount.sh script. I had to comment out line 134, which was throwing an error. "done." isn't a valid command.

Should be when ending a while loop... Strange, will check. To be continued!

Can't reproduce that. Script is still working fine here.

The only thing I could think of is some kind of encoding fudge-up somewhere that would misread the script itself but that's very far-fetched. I pulled it through a few linters and while there is some room for improvement, no such hard errors were apparent. I also can not reproduce.

I just went back and uncommented the line and it's working fine now. My FreeNAS has been up and running since I replaced a failed disk 3 weeks ago and I didn't make any changes to NFS or the filesystem settings since the last boot. The only thing I did change was to the SMART tests on 2 VHDs and 3 other disks, none of which were part of the array that my MiSTer share is on and wouldn't affect anything if they were. I hadn't even logged into the VMware hypervisor since the last boot.
Strange.

Native NFS support would be great

What do you mean by native?

Bas wrote: ↑Mon Jun 03, 2024 5:53 pm

What do you mean by native?

AFAICT NFS isn’t available by default and requires a custom kernel

dickhardpill wrote: ↑Mon Jun 03, 2024 6:11 pm

Bas wrote: ↑Mon Jun 03, 2024 5:53 pm

What do you mean by native?

AFAICT NFS isn’t available by default and requires a custom kernel

No, you are wrong. Native NFS support is available since spring 2023.

RealLarry wrote: ↑Mon Jun 03, 2024 6:30 pm

No, you are wrong. Native NFS support is available since spring 2023.

Can you tell me how? I would greatly appreciate it. I haven't had any luck mounting an NFS partition

The kernel has indeed had support for quite a while and the NFS mount script works. The NFS protocol is quite full of dragons itself, but as long as your server can do NFSv4 things should be good with the script and a current kernel.

I can get NFS working from literally every other box in my house. It simply does not work on my MiSTer.
I will wait until (hopefully) a native NFS client is available.

I couldn't find nfs_mount.sh outside of this thread,, but previous posts say it was added to main. I tried editing the nfs_mount.sh to suit my needs but it did not work. I don't know what I'm missing.

Edited to add-
found the script on github. going to give it another try.

The docs to the script live here nowadays:

https://code.area536.com/Public/misternfs

Thank you, instructions definitely help.

I will say the old fstab would still be preferable but I'm definitely happy to have this.