| Both sides previous revisionPrevious revision | Next revisionBoth sides next revision |
| slackware:samba [2006/03/29 19:11] – alien | slackware:samba [2006/03/29 19:17] – alien |
|---|
| </code> This creates three exports, all accessible by any client with an IP address in the range ''192.168.0.0/24''. I'll discuss them in reverse order: | </code> This creates three exports, all accessible by any client with an IP address in the range ''192.168.0.0/24''. I'll discuss them in reverse order: |
| - the ftp server's 'pub' directory aka the anonymous ftp area. This export will be available as read-only (the 'ro' parameter) with as safe as possible settings | - the ftp server's 'pub' directory aka the anonymous ftp area. This export will be available as read-only (the 'ro' parameter) with as safe as possible settings |
| - your webserver's DocumentRoot (/var/www/htdocs) which will be available as writable, but on the server side, all writes will appear to be done by the user with the userid:groupid of ''99:99'' which is actually the "nobody" user. If you make the DocumentRoot owned by this account (a configuration you often see, so that the Web Server's CGI or PHP scripts can write files in these directories) | - your webserver's DocumentRoot (/var/www/htdocs) which will be available as writable, but on the server side, all writes will appear to originate from the user with the userid:groupid of ''99:99'' which is actually the "nobody" user. If you let the DocumentRoot tree be owned by this account (a configuration you often see), then the Web Server's CGI or PHP scripts can write files in these directories |
| - the server's ''/home'' directory tree which can be mounted writable (the 'rw') using asynchronous transfers (faster but with a chance of data corruption in case of a server crash - 'sync' is safe but slower). User ID's (//uid//) and group ID's (//gid//), even for user 'root' will be mapped 1-on-1 (the 'no_root_squash' option). This means, if the server knows a user 'alien' with a "uid:gid" pair of ''1001:100'', then you will see this uid:gid number pair on the NFS client side as well! So, if the NFS client PC also knows a user 'alien' with the same "uid:gid" number pair of ''1001:100'', he will be able to use the files on the server as they were his own. | - the server's ''/home'' directory tree which can be mounted writable (the 'rw') using asynchronous transfers (faster but with a chance of data corruption in case of a server crash - 'sync' is safe but slower). User ID's (//uid//) and group ID's (//gid//) will be mapped 1-on-1 (even for user 'root' - the 'no_root_squash' option). This means, if the server knows a user 'alien' with a "uid:gid" pair of ''1001:100'', then alien's files in his homedirectory will appear with this uid:gid number pair on the NFS client side as well! So, if the NFS client PC also has an account 'alien' with the same "uid:gid" number pair ''1001:100'', this alien will be able to use the files on the server as they were his own. |
| <note important>You see why it is important to create users on your LAN with the same UID (and GID) on //all// computers if you ever intend to install a NFS server.</note> | <note important>You see why it is important to create users on your LAN with the same UID (and GID) on //all// computers if you ever intend to install a NFS server.</note> |
| |
