NFS e utente

[ribbaldone]

Ciao a tutti,
ho un problema di utenti con il mio NAS QNAP 210.
Mi spiego meglio, nel nas ho settato gli utenti e password per accedere alle varie cartelle. Accedo a Ubuntu con lo stesso utente, e questo mi permette di collegarmi da remoto al disco senza dover inserire utente e password.
La cosa strana è che ho accesso in scrittura e lettura esattamente come dai settaggi del NAS, solo che i file risultano creati dall'utente 1000 e questo non mi permette di utilizzarli da un pc differente nel caso win XP accedendo con lo stesso utente.
Non capisco perchè i file risultino creati dall'utente 1000 e non da quello inserito nel login.

ciao

[eaman]

NFS lavora su IP, non su utenti (come fa samba). Quindi sara' poi il sistema operativo una volta montato il filesystem a preoccuparsi di gestire i permessi in base agli utenti.

Il che e' un problema nel momento in cui si ha la necessita' di sincronizzare utenti e gruppi (UID e GID) su macchine diverse. L'ideale sarebbe all'interno di una rete aziendale avere un sistema centrale di autenticazione, in una piccola LAN domestica invece si puo' "aggiustare" a mano gli utenti cercando di tenere omogenee UID e GID nel file /etc/passwd. Ad es 1000 e' tipicamente la UID del primo utente di sistema creata nel sistema operativo: se ci si assicura che questo sia consistente su tutti i sistemi oppure si crea una UID precisa come 2000 per gli utenti personali non ci sono problemi.

Altrimenti ci sono gli accessi anonimi, oppure esportare i filesystem con una UID/GID ben precisa: tipo con anonuid and anongid

User ID Mapping
nfsd bases its access control to files on the server machine on the uid and gid provided in each NFS RPC request. The normal behavior a user would expect is that she can access her files on the server just as she would on a normal file system. This requires that the same uids and gids are used on the client and the server machine. This is not always true, nor is it always desirable.

Very often, it is not desirable that the root user on a client machine is also treated as root when accessing files on the NFS server. To this end, uid 0 is normally mapped to a different id: the so-called anonymous or nobody uid. This mode of operation (called 'root squashing') is the default, and can be turned off with no_root_squash.

By default, exportfs chooses a uid and gid of 65534 for squashed access. These values can also be overridden by the anonuid and anongid options. Finally, you can map all user requests to the anonymous uid by specifying the all_squash option.

Here's the complete list of mapping options:
root_squash
Map requests from uid/gid 0 to the anonymous uid/gid. Note that this does not apply to any other uids or gids that might be equally sensitive, such as user bin or group staff.
no_root_squash
Turn off root squashing. This option is mainly useful for diskless clients.
all_squash
Map all uids and gids to the anonymous user. Useful for NFS-exported public FTP directories, news spool directories, etc. The opposite option is no_all_squash, which is the default setting.
anonuid and anongid
These options explicitly set the uid and gid of the anonymous account. This option is primarily useful for PC/NFS clients, where you might want all requests appear to be from one user. As an example, consider the export entry for /home/joe in the example section below, which maps all requests to uid 150 (which is supposedly that of user joe).
Example
# sample /etc/exports file
/ master(rw) trusty(rw,no_root_squash)
/projects proj*.local.domain(rw)
/usr *.local.domain(ro) @trusted(rw)
/home/joe pc001(rw,all_squash,anonuid=150,anongid=100)
/pub *(ro,insecure,all_squash)
/srv/www -sync,rw server @trusted @external(ro)
/foo 2001:db8:9:e54::/64(rw) 192.0.2.0/24(rw)
/build buildhost[0-9].local.domain(rw)
The first line exports the entire filesystem to machines master and trusty. In addition to write access, all uid squashing is turned off for host trusty. The second and third entry show examples for wildcard hostnames and netgroups (this is the entry '@trusted'). The fourth line shows the entry for the PC/NFS client discussed above. Line 5 exports the public FTP directory to every host in the world, executing all requests under the nobody account. The insecure option in this entry also allows clients with NFS implementations that don't use a reserved port for NFS. The sixth line exports a directory read-write to the machine 'server' as well as the '@trusted' netgroup, and read-only to netgroup '@external', all three mounts with the 'sync' option enabled. The seventh line exports a directory to both an IPv6 and an IPv4 subnet. The eighth line demonstrates a character class wildcard match.
Files

/etc/exports

Ma magari non e' il caso: meglio usare CIFS/SAMBA nei casi in cui si vuole lavorare su privilegi basati su utenti. Infatti CIFS permette di mantenere un elenco di accoppiate utenete/password diverso da quello del sistema operativo, oppure di montare filesystem impostando come opzione quale utente utilizzare.

[ribbaldone]

Grazie,
darò un occhio con calma.
Ho scelto NFS perchè è più veloce di samba. Pensavo però che i file finissero creati dall'utente con cui ci si è loggati.

Ciao

Originariamente inviato da eaman

NFS lavora su IP, non su utenti (come fa samba). Quindi sara' poi il sistema operativo una volta montato il filesystem a preoccuparsi di gestire i permessi in base agli utenti.

Il che e' un problema nel momento in cui si ha la necessita' di sincronizzare utenti e gruppi (UID e GID) su macchine diverse. L'ideale sarebbe all'interno di una rete aziendale avere un sistema centrale di autenticazione, in una piccola LAN domestica invece si puo' "aggiustare" a mano gli utenti cercando di tenere omogenee UID e GID nel file /etc/passwd. Ad es 1000 e' tipicamente la UID del primo utente di sistema creata nel sistema operativo: se ci si assicura che questo sia consistente su tutti i sistemi oppure si crea una UID precisa come 2000 per gli utenti personali non ci sono problemi.

Altrimenti ci sono gli accessi anonimi, oppure esportare i filesystem con una UID/GID ben precisa: tipo con anonuid and anongid


Ma magari non e' il caso: meglio usare CIFS/SAMBA nei casi in cui si vuole lavorare su privilegi basati su utenti. Infatti CIFS permette di mantenere un elenco di accoppiate utenete/password diverso da quello del sistema operativo, oppure di montare filesystem impostando come opzione quale utente utilizzare.