You are not logged in.
Hello,
since Sunday I'm unable to mount NFS shares:
mount.nfs: No such device
The server-side is working fine, I can mount all shares from my FreeBSD Desktop machine.
I'm using netcfg and start rpcbind and nfs-common upong connection before mounting NFS shares (via netfs). Is this maybe related to some recent pacman updates? It was working flawless just until Sunday.
Offline
Same problem as this thread?
https://bbs.archlinux.org/viewtopic.php?id=74078
Last edited by drrossum (2012-01-23 19:11:41)
Offline
Same problem as this thread?
https://bbs.archlinux.org/viewtopic.php?id=74078
Yes, partially. If I manually insert the module with modprobe, everything works fine. I added it to the MODULES array in rc.conf which gives a warning at boot time that inserting user specified modules failed to load.
Is that maybe related to all the recent udev woes? (https://bbs.archlinux.org/viewtopic.php?id=134012&p=2)
Offline
Anybody figure out a solution to this yet?
I've got the exact same problem on four different boxes after the pacman -Syu last week.
After modprobe nfs
and mount -a
all is well. But that is a pain to do on every boot.
Jim
Offline
I seem to be unaffected by this, but then again: I have setup a networkmanager-recipe to start the nfs-daemons and mount my NFS-shares *only* when connected to my wireless network...
It might be useful to look into that solution/workaround. Your pc won't be trying to mount the shares if you're in a different location, which means one less security-risk.
Offline
Same here. Two Arch machines... NFS no worky at all. Very distressing. I'm guessing none of the devs use nfs.
Offline
It's working for mer and my rc.conf;
DAEMONS=(syslog-ng dbus network rpcbind nfs-common @netfs @ufw @crond @sshd @alsa )
But, I've been mounting my nfs4 share from rc.local for a long time, before that I used to use fstab but it stopped working (maybe to early in the boot chain?)
mount -t nfs4 -o rw,hard,async,intr,rsize=49152,wsize=49152,proto=tcp ...
Offline
I know it doesn't help much, but I can confirm NFS (v4) still works mighty fine on my LAN and my brother's (I sync daily).
Maybe try including the nfs module in the initramfs (I know it's a long shot, but maybe it helps).
I'm guessing none of the devs use nfs.
Nop, you're right. They all run Windows and they are actually writing a pacman port in Silverlight.
Last edited by .:B:. (2012-02-21 11:54:52)
Got Leenucks? :: Arch: Power in simplicity :: Get Counted! Registered Linux User #392717 :: Blog thingy
Offline
I get a [FAIL] when starting nfs-common.
Running the script manually shows it errors out because portmap isn't running (it is, naturally). Can anyone reproduce?
+ [[ ! -f /run/daemons/rpcbind ]]
+ rc=0
+ '[' yes = yes ']'
+ stat_busy 'Starting rpc.statd daemon'
+ printf ':: Starting rpc.statd daemon '
:: Starting rpc.statd daemon + printf '\e[s'
+ deltext
+ printf '\e[177G'
+ printf ' [BUSY] '
[BUSY] ++ get_pid /usr/sbin/rpc.statd
++ pidof -o %PPID /usr/sbin/rpc.statd
+ PID=970
+ '[' -z 970 ']'
+ stat_fail
+ deltext
+ printf '\e[177G'
+ printf ' [FAIL] \n'
[FAIL]
+ exit 1
Offline
As it turns out, It now works. I did load the nfs module manually during my troubleshooting but it was already loaded or built into the kernel or whatever.
The thing that made it work is changing the nfs mount lines in /etc/fstab from the hostname of the server to the ip address of the server. I don't know why that worked on both machines since I could ping the hostname of the nfs server which is a Freenas server and it always worked before.
@ jasonwryan
rc.d start rpcbind && rc.d start nfs-common
start fine after stopped and restarted. Have you replaced portmap with rpcbind in pacman? rpcbind superceded portmap a while back. gl.
@.:B:.
lol, snide remark succesfully detected. In my defense I was half guessing and half sniding (or some percentage thereof). I have to admit I do get a bit snippy over this since nfs is necessary for my little clients to run mpd and I gets a bit cranky when I gots no musics! Fueling my frustration, it seems I have to chase down nfs problems frequently after "pacman -Syu".
Offline
Yes: rpcbind starts fine (and, you can see the PID in the nfs-common startup script), but for whatever reason nfs-common doesn't seem to accept that fact...
Offline
I'm no expert (by any stretch) but are you starting from rc.conf? And isn't rpcbind a separate daemon than rpc.statd?
I think you need dbus started before rpcbind as well, iirc.
DAEMONS=(hwclock syslog-ng dbus network rpcbind nfs-common @netfs ...etc )
... just flailing around in the dark here.
Offline
For the record: my rc.conf
DAEMONS=(syslog-ng dbus crond ufw @atd @sshd @alsa @acpid @network @privoxy @rpcbind @nfs-common @nfs-server @cupsd)
Offline
I think I vaguely remember having trouble backgrounding rpcbind. Maybe try removing the @ and maybe forground the network as well...?
Offline
For the record: my rc.conf
DAEMONS=(syslog-ng dbus crond ufw @atd @sshd @alsa @acpid @network @privoxy @rpcbind @nfs-common @nfs-server @cupsd)
The only thing I background is network because it might get tied up if you're unplugged, but other than that most of those services don't take that long to start up so backgrounding all of those isn't necessary.
Last edited by nomorewindows (2012-02-22 14:50:01)
I may have to CONSOLE you about your usage of ridiculously easy graphical interfaces...
Look ma, no mouse.
Offline
I think I vaguely remember having trouble backgrounding rpcbind. Maybe try removing the @ and maybe forground the network as well...?
Thank for the pointer: unbackgrounding those services worked. I don't understand why, unless backgrounding them changes the order in which they start.
The only thing I background is network because it might get tied up if you're unplugged, but other than that most of those services don't take that long to start up so backgrounding all of those isn't necessary.
They are only backgrounded because I don't need them at startup - so it wasn't necessity just indifference behind the decision.
I'll update the wiki to reflect the fact that you can't background those daemons.
Offline
I'm certain nfs-common needs rpcbind to be fully functional to start and I suspect rpcbind needs network fully functional but I'm too lazy to test it again.
Offline
Offline