Tiny Core Linux
Tiny Core Extensions => TCE Q&A Forum => Topic started by: bigpcman on April 30, 2009, 04:50:44 PM
-
I'm trying to get nfs to work on tc2rc1. I've installed the nfs_utils and modified the exports file to include:
/home/tc 192.168.0.114(rw,insecure,no_root_squash)
I started nfs using the jwm menu and see that portmap, rpc.statd and rpc.mountd have all started. I then tried to access the server with a nfs client and receive an error message path not found after a long delay. The nfs client shows the nfs server (192.168.0.100) as part of the nfs network default LAN but that's as far as I get. I use http://192.168.0.100:/home/tc as the server address.
Note that "exportfs -a" generates error messages "can't open exports or rmtab for reading".
Any ideas would be appreciated.
-
Whem moving nfs-utils to 2.x I removed the .dep file that contained the filesystems kernel module extension and nfs server will not work without it. I will add the filesystems extension to the info file instead since it is not needed for nfs client support, which would be probably the most common use.
/etc/mtab is a symlink and I get that mtab error as well but all works well even with the error.
I will look at my setup when I get home to see what else needs to be done for using tc as an nfs server. I can't remember off the top of my head.
-
I am running TC 1.x as my nfs server, and I can't see anything beyond the standard nfs configuration that I did.
-
I am running TC 1.x as my nfs server, and I can't see anything beyond the standard nfs configuration that I did.
Do you mean after "filesystems-2.6.26.tcem" is added as a dependency and installed with portmap.tce and tcp_wrappers.tcel ?
-
Yes, filesystems-2.6.26.tcem must be loaded.
-
Ok, I'm getting a little farther now. The nfs probe now seems happy and the pingNFS gets a full response but the show exports returns nothing. It looks like the exportfs is not updating correctly. I now get "could not open or lock errors" on exports, rmtab, etab, and xtab. I tried exportsfs with nfs started and stopped, no difference. Any ideas?
edit:
I added "/home/tc 192.168.0.114(rw,insecure,no_root_squash)" to the "exports" file as I said before and now get "access denied enter another user name and password" from the client when I try and access "192.168.0.114:/home/tc". So I entered user name tc and my password and get the same response. But at least the client has a valid path now.
edit2: attached nfs client trace log.
-
tc2rc1
I'm still trying to get nfs working on tc2rc1 without success. The "exports" file modifications do not transfer to /var/lib/nfs/etab after executing the "exportfs -ra" command. Actually all of the files etab,rmtab and xtab are empty. I'm using the instructions from the nfs faq below. Does anyone else have this working? If so I will put this aside.
C1. How are exported file systems and client mount points tracked on the server?
A. /etc/exports contains information about how file systems should normally be exported. This is only read by exportfs.
/var/lib/nfs/etab contains information about what filesystems should be exported to whom at the moment.
/var/lib/nfs/rmtab contains a list of which filesystems actually are mounted by certain clients at the moment.
/proc/fs/nfs/exports contains information about what filesystems are exported to actual client (individual, not subnet or whatever) at the moment.
/var/lib/nfs/xtab is the same information as /proc/fs/nfs/exports but is maintained by nfs-utils instead of directly by the kernel. It is only used if /proc isn't mounted.
C2. Can I modify export permissions without needing to remount clients in order to have them take effect?
A. Yes. The safest thing to do is edit /etc/exports and run "exportfs -r".
Note that when a mount request arrives, mountd check .../etab to see if that host is allowed access. If it is, an entry is placed in .../rmtab and the filesystem is exported thus creating an entry in /proc/fs/nfs/exports.
-
The files in /var/lib/nfs exist in the extension so there may be a permissions error. I made the extension before we had startup scripts I believe, and if the files must exist then creating them with the touch command in the script may work better. If the files themselves to not have to exist then creating the directory may be all that is needed. I will check on it tonight.
-
The files in /var/lib/nfs exist in the extension so there may be a permissions error. I made the extension before we had startup scripts I believe, and if the files must exist then creating them with the touch command in the script may work better. If the files themselves to not have to exist then creating the directory may be all that is needed. I will check on it tonight.
Thanks. I did a chmod 777 on all the etab,rmtab and xtab files as a brute force test and that did not change anything. Is there anything else you would like me to try? I've dedicated today to testing tc2rc1.
-
One more thing I will look at tonight is that the files may need to exist in /usr/local/var/lib/nfs since it was compiled to /usr/local. I will check and see and hopefully get it straight.
-
please someone fix that bloody
tag...
-
/var/lib/nfs is the right spot. Here are my file contents:
tc@box:~$ cat /var/lib/nfs/etab
/mnt/hda2/data 192.168.0.*(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no_all_squash,no_subtree_check
,secure_locks,acl,anonuid=65534,anongid=65534)
/mnt/sda1 192.168.0.*(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no_all_squash,no_subtree_check,
secure_locks,acl,anonuid=65534,anongid=65534)
tc@box:~$ cat /var/lib/nfs/rmtab
192.168.0.101:/mnt/sda1:0x00000008
192.168.0.103:/mnt/sda1:0x00000002
tc@box:~$ cat /var/lib/nfs/state
tc@box:~$ cat /var/lib/nfs/xtab
/mnt/sda1 192.168.0.101(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no_all_squash,
no_subtree_check,secure_locks,acl,anonuid=65534,anongid=65534)
tc@box:~$
-
/var/lib/nfs is the right spot. Here are my file contents:
tc@box:~$ cat /var/lib/nfs/etab
/mnt/hda2/data 192.168.0.*(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no_all_squash,no_subtree_check
,secure_locks,acl,anonuid=65534,anongid=65534)
/mnt/sda1 192.168.0.*(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no_all_squash,no_subtree_check,
secure_locks,acl,anonuid=65534,anongid=65534)
tc@box:~$ cat /var/lib/nfs/rmtab
192.168.0.101:/mnt/sda1:0x00000008
192.168.0.103:/mnt/sda1:0x00000002
tc@box:~$ cat /var/lib/nfs/state
tc@box:~$ cat /var/lib/nfs/xtab
/mnt/sda1 192.168.0.101(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no_all_squash,
no_subtree_check,secure_locks,acl,anonuid=65534,anongid=65534)
tc@box:~$
Jason are you running tc2rc1 with the nfs and files systems extensions?
-
I am running 1.2 on the nfs server.
-
Not sure if I should be adding my question to this thread or if it would be more appropriate to start a new one but here goes.
I've been trying unsuccessfully to get nfs-server going on a PPI/TCE install of TC1.3.
I was getting some of the same error messages as bigpcman ("can't open exports or rmtab for reading") but now that I've managed to get past those, when I try to start to start the nfs-server ("/usr/local/etc/init.d/nfs-server start"), I get "FATAL: Module nfsd not found."
I checked and "filesystems-2.6.26.tcem" is installed.
Does this have anything to do with my chosen mode of operation?
I ask because I was experiencing similar problems when trying to compile from source ("compiletc.tce" was installed but "make" error messages suggested it wasn't). The problems went away when I ran Tiny Core from the live CD (PPR/TCE).
Is there soething basic I'm missing about the Tiny Core design concept here?
-
compiletc.tce as well as filesystems-2.6.26 are not PPI compatible and need to be loaded each boot.
-
I tend to gravitate towards small foot print / minimalist distros (Arch, Slitaz are favorites), hence my interest in Tiny Core.
I like that I can build TC with only the extensions that I want, as opposed to DSL or Puppy, which come with software I do not need or use.
I also like that TC runs on my Compaq laptop (Pentium MMX @ 133MHz with 48MB of RAM). My goal is to use this machine as an always on webserver on a small LAN. I'd like to be able to access the HTML files hosted on it from another PC on the LAN via NFS.
That said, I understand that running on older hardware is NOT one of TC's primary goals.
All of which brings me to the following questions:
1. What is the technical nature of PPI incompatibilities with extensions like "compiletc.tce" and "filesystems-2.6.26" ? Very little information seems to be available on this topic (on the Core Concepts page, for example).
2. Does there exist a work-around, short of using a different mode of operation?
In closing, I'd like to say that I am a just an average Linux enthusiast - i.e., not a developer with a degree in Computer Sciences - but I am willing to learn and I commend the Tiny Core developers on an EXCELLENT distro.
-
cannonfodder-
I share your interest in older hardware as that is mostly what I use.
Many who wish to use TC as an nfs server will be using old hardware, so
I will make an nfsd module extension that is PPI compatible so that only
the nfsd kernel module will be installed for those using the nfs-utils package.
It will be in TCZ and TCE format, supporting all modes.
-
1. What is the technical nature of PPI incompatibilities with extensions like "compiletc.tce" and "filesystems-2.6.26" ? Very little information seems to be available on this topic (on the Core Concepts page, for example).
Basically to be PPI compatible, all the files in an extension need to be in /usr/local as it is this directory that is made permanent - files outside /usr/local will be lost on boot. The files in compiletc are in /usr, /lib, etc and thus are lost on reboot in a PPI system
-
Note that in TC 2.x the module extensions are PPI compatible. There one would only need to load the nfs extension on boot.
-
In that case, would it be ok to make the filesystems-2.6.26
extension PPI compatible as an nfs server machine will always have
hard drive space for tclocal/PPI. No need then for an nfsd extension.
-
Sure
-
Thank you Jason W, Juanito and curaga for your prompt and complete replies.
I don't usually post in forums - either my posts have gone unanswered or unresolved. The support here so far has been outstanding.
-
filesystems-2.6.26 in TC 1.x is now PPI compatible. For minimal ram usage without PPI the tcz format is recommended.