Search the Community
Showing results for tags 'autofs'.
Background: I hate CIFS/Samba (just kidding, I loathe that technology) so my setup consists of a CentOS server that also acts as an NFS server containing all of my media. Emby runs on a separate Debian server, and it mounts the NFS shares via autofs. I have been wondering why my metadata was not getting saved back to the media directories on my NFS exports. So I got off my lazy arse and actually started to do some real troubleshooting. Initially, my /etc/exports consisted of shares configured like so: /srv/nfs/media 192.168.100.0/24(rw,async,no_root_squash) And on my Debian server running Emby, my autofs setup is something like this: auto.misc movies -fstype=nfs,rw NFSSERVER:/srv/nfs/media/Movies tv -fstype=nfs,rw NFSSERVER:/srv/nfs/media/TV Emby never had issues mounting these directories when needed, and reading data from them. But it could not write any metadata back to the shares (.nfo files, posters, etc.). Instead, it would give me "permission denied" messages in the logs, and instead write the metadata files into the /var/lib/emby structure on the Debian server. So first I looked into the UID and GID that Emby was using. On my Debian installation, the ID mappings look like this: uid=998 gid=998 However, I once had Emby running on a separate CentOS installation, and the mappings were different: uid=988 gid=988 No idea as to why, that's just how it was. Initially, I thought that maybe I just needed to add an 'emby' account to my CentOS host, using the same uid/gid pair. But I couldn't do that, as 998 on CentOS was reserved for the 'irc' service, at least on my installation. No big deal, the 'video' group exists on both installations, so I'll make Emby a member of that group on the CentOS installation, as it is already a member of that group under my Debian host. So I set up an 'emby' user on my CentOS server: useradd -s /sbin/nologin -u 998 -G video -M -r emby Neato. Now I go and attempt to "Refresh Metadata" on a movie, and check the share. No metadata is written. Well, damn. I look at the logs, and it still says "permission denied". I double check the uid and gid on both systems. Well, there was a mismatch (because god-forbid we should have our Linux distributions agree on some things). The GID for 'video' was different between both installations: Centos: video gid = 49 Debian: video gid = 44 No worries, I'll change the GID on my CentOS install (making sure that the number would not conflict with another group): sudo groupmod -g 49 video Another attempt at refreshing metadata.... permission denied. Ok, well the GID now matches between both hosts, so let's set up the exports so that the group has ownership of anything written to that directory. This is the typical approach that would be taken under such circumstances, and is typically the final solution to such a problem. sudo chmod g+s /srv/nfs/media Ok, so now things look like this: drwxrwsr-x emby video /srv/nfs/media Another attempt to refresh metadata. Another failure. What the hell? Emby is in the correct group, it has full write access to that location, and the group has ownership of that directory! Just for grins and giggles, I went nuclear: sudo chmod -R 777 /srv/media After another "Refresh Metadata" round, still no dice. How on Earth is this still not working? I started to mess around with ACL's to try and fine-tune the permissions more, even changing the mask value for this export. Nothing was working. I even tried doing a SUID on the directory, but the Linux kernel (smart for security, anyway) will typically ignore such requests. Then I got smarter. I went and looked at man(5) exports. Instead of doing a 'no_root_squash', I could instead do a 'all_squash'. This forces all new entries written via NFS to effectively use the UID and GID of 65534 (known as the anonymous UID and GID). But, I can force the anonymous UID and GID to match the UID and GID for the 'emby' account on my CentOS server. I changed the export to: /srv/nfs/media 192.168.100.0/24(rw,async,all_squash,anonuid=998,anongid=49) Re-exported the share: sudo exportfs -a Ran another metadata refresh... SUCCESS! In summary, even though the GID matched, the Emby service was still unable to write to the share as I'm guessing either the Emby service or the NFS service needed the UID to be the effective owner of the directory of where the data was going to be written to. Anyways, maybe this will help someone else out or whatever, but I thought that I would share my experience on this fun exercise in permissions.