구차니의 잡동사니 모음

집에와서 공유기 빼고 해보니 자~알 된다 -_-
아마도 공유기(D-LINK DI-524) 모델이 1024번 이하에 대해서 제대로 열어주지 못하는게 아닐까 조금 의심이 된다.
showmount 시에 RPC timeout이 된 것 봐서는 111번 포트를 매~우 유력한 후보로...

--- 삭제(백업용) ---
회사는 둘다 KT 망을 사용하는데
동일 건물이라서 그런지 nfs를 붙이는데 아무런 이상이 없다.(물론 둘다 10.04 LTS ubuntu desktop)
하지만 집의 녀석과 붙이려니 요런 에러를 뱉어주신다.  (12.04 LTS ubuntu desktop)
  mount 에서는    mount.nfs: access denied by server while mounting
  dmesg 에서는   nfsd: last server has exited, flushing export cache 

이래저래 고민을 해보니.. 집은 SK(구, 하나로 케이블) 라서 인가? 이런 고민도 드는데..
강제로 -o vers=3 를 통해 구버전으로 맞춰줘도 여전한걸 보니..
1024번 이하의 포트를 막아둔게 아닐까라는 의심이 새록새록..

 반대 방향으로 해보니 된다... 도대체 머가 문제지 -_- 
혹시.. no_subtree_check 이녀석 문제인가? << 이건 아님 ㅠ.ㅠ

no_subtree_check This option disables subtree checking, which has mild security implications, but can improve reliability in some circumstances. If a subdirectory of a filesystem is exported, but the whole filesystem isn't then whenever a NFS request arrives, the server must check not only that the accessed file is in the appropriate filesystem (which is easy) but also that it is in the exported tree (which is harder). This check is called the subtree_check. In order to perform this check, the server must include some information about the location of the file in the "filehandle" that is given to the client. This can cause problems with accessing files that are renamed while a client has them open (though in many simple cases it will still work). subtree checking is also used to make sure that files inside directories to which only root has access can only be accessed if the filesystem is exported with no_root_squash (see below), even if the file itself allows more general access. As a general guide, a home directory filesystem, which is normally exported at the root and may see lots of file renames, should be exported with subtree checking disabled. A filesystem which is mostly readonly, and at least doesn't see many file renames (e.g. /usr or /var) and for which subdirectories may be exported, should probably be exported with subtree checks enabled. The default of having subtree checks enabled, can be explicitly requested with subtree_check. From release 1.1.0 of nfs-utils onwards, the default will be no_subtree_check as subtree_checking tends to cause more problems than it is worth. If you genuinely require subtree checking, you should explicitly put that option in the exports file. If you put neither option, exportfs will warn you that the change is pending.   [링크 :  http://linux.die.net/man/5/exports]

showmount로 해보니 이런 에러 발생 -_-
clnt_create: RPC: Port mapper failure - Timed out 

설마.. 공유기 문제는 아니려나? 

원격지의 nfs 서버의 exports 목록을 보여주는 명령어이다.

$ showmount -e [ip_address|url]

[링크 :  http://nixcraft.com/...nfs-server-mount-nfs-access-denied-server-while-mounting-...-shared-folder.html]
[링크 :  http://linux.die.net/man/8/showmount]

kernel-nfs-server 패키지를 설치하지 않고 nfs로 붙이려고 하니
/proc/filesystem에 nfs를 지원하다고 나옴에도 불구하고 붙어지질 않는다.
그런 이유로 nfs를 mount 하기 위해서는  kernel-nfs-server 패키지를 설치해야한다
(/etc/exports를 비워두거나 서비스를 실행하지 않도록 설정필요)

mount: wrong fs type, bad option, bad superblock on server:/path,        missing codepage or helper program, or other error        (for several filesystems (e.g. nfs, cifs) you might        need a /sbin/mount.<type> helper program)        In some cases useful info is found in syslog - try        dmesg | tail  or so

NFS로 마운트 하고 나서 보기에는 문제가 없어 보이지만
실제로 파일을 복사해 넣으려고 하면 위와 같은 에러가 발생한다.

sudo cp 를 해도 여전히 문제가 해결되지 않는데 이는 NFS의 권한 문제 때문이다. 

$ cat /etc/exports /home (rw)

라고만 nfs를 공유할 경우,
기본값으로 root_squash  옵션이 들어가며, 이런 이유로 rw가 들어가더라도 권한이 맞지 않아 파일을 생성할 수 없게 된다. 
(anonymous 권한으로 설정이 되는데, 이러한 이유로 nobody:nogroup 권한으로 파일이 생성되며, other 권한이 rw- 일 경우 제한적으로 파일이 생성되기도 한다. 물론 디렉토리 권한한 기본 퍼미션 마스크를 따르기 때문에 하위 디렉토리 부터는 안될수도 있다)

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 that might be equally sensitive, such as user bin. 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).  [링크 : http://linux.die.net/man/5/exports]

NFS는 보안상의 문제가 있어서 되도록이면 외부접속은 하지 않는게 정석이지만,
꼭 해야 한다면 다음의 절차를 거치면 된다.


1. mountd 서비스 포트 고정
/etc/services 에 mountd를 특정포트로 고정한다.
[링크 : http://mindwing.kr/141]

2. 공유기에서 포트 포워딩
rpcinfo -p 에서 나오는 portmapper 와 nfs 그리고 mountd 포트를 포워딩 해준다.
(111번 그리고 2049번 위에서 설정한 mountd 포트를 포워딩하면 된다)

$ rpcinfo -p    program vers proto   port     100000    2   tcp    111  portmapper     100000    2   udp    111  portmapper     100024    1   udp  58095  status     100024    1   tcp  49200  status     100021    1   udp  44937  nlockmgr     100021    3   udp  44937  nlockmgr     100021    4   udp  44937  nlockmgr     100021    1   tcp  50652  nlockmgr     100021    3   tcp  50652  nlockmgr     100021    4   tcp  50652  nlockmgr     100003    2   udp   2049  nfs     100003    3   udp   2049  nfs     100003    4   udp   2049  nfs     100003    2   tcp   2049  nfs     100003    3   tcp   2049  nfs     100003    4   tcp   2049  nfs     100005    1   udp  36811  mountd     100005    1   tcp  33175  mountd     100005    2   udp  36811  mountd     100005    2   tcp  33175  mountd     100005    3   udp  36811  mountd     100005    3   tcp  33175  mountd

/etc/exports 에 nfs로 마운트할 아이피를 포함하여 작성한다.

Target 보드용 RootFS를 사용하기 위해 NFS를 사용하다 보니
확실히 NFS는 개발용으로는 좋으나 원격지에 대해서 물려쓰기에는 상당히 보안이 취약하다는 생각이 든다.
최소한 접속할 IP 대역을 제한해놓는다던가 하는 시스템적인 구현이 필요해 보인다.

sNFS와 같은 SSH를 통한 NFS등도 존재는 하지만
구조적인 보안취약성은 해결하기 힘들듯...

[링크 : http://www.sans.org/reading_room/whitepapers/linux/nfs-security-trusted-untrusted-environments_1956]
[링크 : http://www.lug.or.kr/docs/LINUX/others/00-01-5.htm]
[링크 : http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-sg-ko-4/s1-server-nfs.html]
[링크 : http://165.132.13.12/document/service_info/security/guide/document/unix/unix_nfs.html]

NFS over TCP가 타겟 보드에서 안되는 문제로 인해 검색을 해보고 실험도 해봤지만
이녀석은 mountd 포트를 고정시켜주는 역활을 한다.
아무래도 VMWARE에서 돌릴려면 내부 방화벽이라던가의 문제로 인해서 특정 포트로 고정하는게 편하니까 말이다.

물론 Fedora/redhat 계열의 경우이고
ubuntu의 경우 다른 파일에서 설정을 해야 한다.

아래는 페도라/레드햇 일 경우

$ cat /etc/sysconfig/network NETWORKING=yes HOSTNAME=localhost.localdomain # Add Static ports for NFS, in order to be able to forward them with VMWare NATconfig RQUOTAD_PORT=32764 STATD_PORT=32765 STATD_OUTGOING_PORT=32766 MOUNTD_PORT=32767 [링크 : http://www.stlinux.com/faq?q=faq/vmware]

아래는 우분투/데비안일 경우

$ cat /etc/services | grep mountd mountd             32767/tcp mountd             32767/ucp [링크 : http://manpages.ubuntu.com/manpages/intrepid/man8/mountd.8.html] [링크 : http://mindwing.kr/141]

NFS의 기본설정을 몰라서 헤매다가 nfsstat을 통해 검사를 해보니
서버나 클라이언트에 따라 다르겠지만, FC6 -> ubuntu 9.10 에서는 TCP, NFSver3 로 접속한다.
물론 mount 명령에서는 별다른 옵션은 나오지 않는다.

# /usr/sbin/nfsstat -m /media/nfs from 192.168.10.91:/  Flags: rw,vers=3,rsize=262144,wsize=262144,hard,proto=tcp,timeo=600,retrans=2,sec=sys,addr=192.168.10.91 # mount 192.168.10.91:/ on /media/nfs type nfs (rw,addr=192.168.10.91)

Name nfsstat - list NFS statistics Examples nfsstat -o all -234 Show all information about all versions of NFS. nfsstat --verbose -234 Same as above. nfsstat -o all Show all information about about active versions of NFS. nfsstat --nfs --server -3 Show statistics for NFS version 3 server. nfsstat -m Show information about mounted NFS filesystems. [링크 : http://linux.die.net/man/8/nfsstat]

mount -t nfs servername:directory local_directory
mount -t nfs serverip:directory local_directory

예를 들어
서버 이름이 ubuntu 이고 ip가 192.168.0.2 라면

mount -t nfs ubuntu:/home/ubunutu /mnt/nfs
mount -t nfs 192.168.0.2:/home/ubunutu /mnt/nfs

이런식으로 마운트 하면 된다.

[링크 : http://www.faqs.org/docs/linux_network/x-087-2-nfs.mountd.html]


만약에
Protocol not supported 에러가 발생한다면

-t nfs 대신
-t nfs4를 해보면 된다고 한다.


그것도 안되면 커널을 다시 빌드해야 한다.

File systems ---> Network File Systems <*> NFS file system support [  ]   Provide NFSv3 client support [  ]   Provide NFSv4 client support (EXPERIMENTAL) [링크 : http://www.lslnet.com/linux/edosc/36/linux-36266311.htm]

NFSv3 와 NFSv4를 체크해주면 된다. busybox 문제라기 보다는 커널의 문제이다.

공식문서는 발견하지 못했는데
간단하게 설명을 하자면,  NFS 공유를 통해 열어 놓은 파일을 삭제했을때
파일을 삭제하기 위해 임시 파일을 만든후,
원본을 삭제하고, 이미 공유중인 파일은 숨겨진 파일로 공유가 되는것으로 생각이 된다.

When files on an nfs shared filesystem are deleted while processes still have them open, the nfs server renames them to .nfsXXXXX files. Find those processes and make them close the shared files before you delete them. [링크 : http://unix.derkeiler.com/Newsgroups/comp.unix.aix/2006-04/msg00094.html]

This is quite common -- the file you are trying to delete is still open, and because of that the NFS server has to keep it around, so it renames the file to .nfs You need to figure out what's holding the file open. It could be that there is a process that is still using it, or it could be that the file is actually a shared library which got "stuck" in memory. [링크 : http://dbaspot.com/forums/aix/345512-hidden-nfs-files-aix5-2-a.html]

결론은, 임베디드 개발을 위해 사용하는 NFS에서 이러한 파일들이 생성될 경우 그냥 삭제해주어도 상관은 없다.