Linux NFS crea maschera e forza l'equivalente dell'utente

Ho due server Linux:

fileserver
Debian 5.0.3 (2.6.26-2-686)
Samba versione 3.4.2

apache
Ubuntu 10.04 LTS (2.6.32-23-generico)
Apache 2.2.14

Ho un numero di condivisioni Samba sul file server in modo da poter accedere ai file da PC Windows. Sto anche esportando /data/www-datasul server Apache , dove l'ho montato come /var/www.

Il setup va bene, tranne quando vengo a creare file sul mount NFS. Finisco con i file che non possono essere letti da Apache o che non possono essere modificati da altri utenti sul mio sistema.

Con Samba, posso specificare force user, force group, create maske directory mask, e questo assicura che tutti i file vengono creati con i permessi adatti per il mio server web Apache. Non riesco a trovare un modo per farlo con NFS. Esiste un modo per forzare autorizzazioni e proprietà con NFS: mi sto perdendo qualcosa di ovvio?

Anche se ho trascorso un bel po 'di tempo con Linux e mi sto liberando da Windows, non ho ancora avuto modo di controllare le autorizzazioni di Linux ... Se questo non è il modo giusto di fare le cose, sono aperto a suggerimenti alternativi.

Dato che provieni da Windows, scoprirai che NFS è .... diverso.

Il problema che stai riscontrando è abbastanza comune. NFS sta trasmettendo avanti e indietro l'UID e GID dei file / directory tra le macchine, supponendo che gli ID utente e gruppo siano mappati in modo identico su entrambi . Ciò significa che è possibile ottenere una situazione in cui l'UID / GID sul server viene restituito a un client NFS, ma non può corrispondere nel client /etc/passwdo /etc/group, il che significa nessun accesso.

In un passato (lontano) questo è stato coordinato con NIS e NIS +, anche se ci sono altri schemi che sono stati incastrati in questo framework (Samba's Winbind è uno di questi). Tuttavia, questo richiede un server ID centrale, seguito da molte autorizzazioni per il fissaggio manuale.

Esistono diversi modi per risolvere questo problema, ma il più economico / veloce è quello di creare un gruppo con lo stesso numero ID di gruppo su entrambe le macchine - diciamo, ID gruppo 50000 - e impostare i bit di gruppo sul file server mentre si aggiunge l'utente appropriato al gruppo sul client; quindi utilizzare le autorizzazioni di gruppo sui file per controllare l'accesso. Non è un'ottima soluzione ma funzionerà. Tieni presente che potresti avere problemi con i servizi che modificano esplicitamente il loro gruppo in fase di runtime (noto anche come drop privato) e potresti dover modificare l'impostazione che controlla quale gruppo viene assunto in fase di runtime per assicurarti che sia quello che hai creato.

Per quei file che arrivano in entrata tramite una condivisione di Windows (aka Samba), imponi semplicemente al gruppo di essere uguale a quello che crei. In questo modo tutti i file ottengono automaticamente il GID "giusto".

È inoltre possibile utilizzare l' all_squashopzione che rende anonimi (utente e gruppo) tutti i file e le cartelle esportati e li collega a un GID e UID specifici.

/data/www-data apache(rw,all_squash,anonuid=<your UID>,anongid=<your GID>,sync)

Il problema è che tutti gli utenti sul apacheserver vedranno il tuo mount point nobody nobodycome utente e gruppo e potrebbero scrivere nel mount (ma comunque, sul server Samba, i file verranno creati come <your UID>/ <your GID>).