Please advise on best way of mounting remote Debian share

[rjalex]

For years I had a well working setup where my movie files and their related metadata are hosted on an HDD connected to a Raspberry Linux server running a Debian derivative (Raspbian) and my Vero player devices (also Debian based) used a share from it to play Movies and TV Series.

I also use a Mac app (tinyMediaManager) to enrich my movies and series video files and therefore I also need to mount my remote video files directory in a decent R/W mode from the Raspbian machine to my Sonoma Mac.

Problems cropped up which I don’t even recall and I switched from Samba to AFS then back to (perhaps different levels and settings) of Samba etc. As of today the situation is a mess. I see some movies, I do not reach others, things are super slow etc etc.

Can any kind soul please let me understand what Debian GNU/Linux 12 (bookworm) share to define (NFS, AFS,Samba ? Versions? Options?) and how so it will be well seen by both the Vero 4K player (a fast read mode would suffice) and also from my Mac (where I need a R/W access to write the metadata with TinyMediaManager even if slower).

Thanks for the patience.

 

[Slartibart]

SMB is probably one of your friends here. 🤓

 

[rjalex]

Ok thanks thanks a lot. So this is the rub The machines to have a reliable connection are 3. Two of them are Debian based and then there's the Mac. Someone suggested that NFS is the best protocol for both Linux<->Linux and Mac<->Linux

Performance and the correct management of R/W rights/userids seem to be the most important details to get right.

Right now I have setup NFS between the two Linux devices and it's working like a charm. Not quite so for the same mounted on the Mac. I need to investigate more but am getting a lot of errors related to not being able to write in the tinyMediaManager Mac app ...

 

[Slartibart]

Ok thanks thanks a lot. So this is the rub The machines to have a reliable connection are 3. Two of them are Debian based and then there's the Mac. Someone suggested that NFS is the best protocol for both Linux<->Linux and Mac<->Linux

Performance and the correct management of R/W rights/userids seem to be the most important details to get right.

Right now I have setup NFS between the two Linux devices and it's working like a charm. Not quite so for the same mounted on the Mac. I need to investigate more but am getting a lot of errors related to not being able to write in the tinyMediaManager Mac app ...

If you do not enable Apple’s s longtime beta write support for NFS, or use free or commercial thirdparty software, Macs can only read from NFS.
What version of macOS are you running?

EDIT: OP talks about NFS… momentarily lapsus for my part, sorry.

 

[theluggage]

If you do not enable Apple’s s longtime beta write support for NFS, or use free or commercial thirdparty software, Macs can only read from NFS.
What version of macOS are you running?

That’s NTFS (Windows NT FS) - NFS (Network Filing System) is something completely different.

 

[rjalex]

Sonoma 14.5 but I am trying to use NFS (Network File System), not NTFS (the Microsoft filesystem format born with Windows NT).

 

[Slartibart]

sorry, I wasn’t focused. Assuming you have already a NFS share running, assuming your NFS server allows connections on non-reserved ports (i.e. >1024):

• In Finder, press cmd + k and enter the path to the NFS server/share -> nfs://yourserver/path/to/export

If your NFS server does not allows connections on non-reserved ports for macOS clients to work, you'll have to add the insecure option to your nfs server in your export (see man page exportfs).

• Or you mount in that case on macOS via the terminal:

sudo mount -t nfs -o resvport yourserver:/your/export nfs

 

[theluggage]

Right now I have setup NFS between the two Linux devices and it's working like a charm. Not quite so for the same mounted on the Mac. I need to investigate more but am getting a lot of errors related to not being able to write in the tinyMediaManager Mac app ...

NFS usually assumes that all of the machines connecting share the same numeric user ID and group IDs.

Type the "id" command into the terminal (Mac or Linux) to see the UID and GID for the current user.

If you're mounting between two Debian systems, odds are that the user and group ID numbers match between the machines - so the default user willprobably have UID=1000 and GID=1000 on Debian and they'll all get along swimmingly.

On the Mac, the default user usually has UID=501 (yourusername), GID=20 (staff) - so when the Mac tries to read/write from the NFS share, the Linux box will either see it as an unknown user in an odd group (20 is usually "dialout" on Linux) - and it's also likely that the media files are globally readable but only writable by the owner.

Best solution is to edit the /etc/exports file on the media server to map all network users to the same UID, GID that "owns" the media folder. I think the line in etc/exports would be something like:

/home/media 192.168.0.0/24(rw,all_squash,anonuid=1000,anongid=1000)

Update: the following /etc/exports works for me:

/home/pi 192.168.1.0/24(rw,all_squash,insecure,async,no_subtree_check,anonuid=1000,anongid=1000)

...on a Raspberry Pi with a user pi (UID 1000,GID 1000), on a home network with IP addresses 192.168.1.x

 

[rjalex]

NFS usually assumes that all of the machines connecting share the same numeric user ID and group IDs.

Type the "id" command into the terminal (Mac or Linux) to see the UID and GID for the current user.

If you're mounting between two Debian systems, odds are that the user and group ID numbers match between the machines - so the default user willprobably have UID=1000 and GID=1000 on Debian and they'll all get along swimmingly.

On the Mac, the default user usually has UID=501 (yourusername), GID=20 (staff) - so when the Mac tries to read/write from the NFS share, the Linux box will either see it as an unknown user in an odd group (20 is usually "dialout" on Linux) - and it's also likely that the media files are globally readable but only writable by the owner.

Best solution is to edit the /etc/exports file on the media server to map all network users to the same UID, GID that "owns" the media folder. I think the line in etc/exports would be something like:

/home/media 192.168.0.0/24(rw,all_squash,anonuid=1000,anongid=1000)

Update: the following /etc/exports works for me:

/home/pi 192.168.1.0/24(rw,all_squash,insecure,async,no_subtree_check,anonuid=1000,anongid=1000)

...on a Raspberry Pi with a user pi (UID 1000,GID 1000), on a home network with IP addresses 192.168.1.x

Thanks that's exactly what I do. In my case I am using www-data ID (which is 33) since that's the owner of the directory hosting the video files.