I'm trying to dockerize a rpc application I made using C lang and rpcgen, I have the byte executable and everything, I tried a lot of docker os image like ubuntu 22.04/ debian and so on, the executable run and the rpc service run too but there's no listening to port 111 that can enable me to get the UDP and TCP port numbers so I can connect my external client to it, any solution? this is the Dockerfile

FROM ubuntu:22.04

WORKDIR /app

COPY . .

RUN apt-get update && \
    apt-get install -y rpcbind && \
    mkdir -p /run/sendsigs.omit.d && \
    chmod +x run.sh

CMD rpcbind && ./run.sh

this is the shell script

#!/bin/sh
./server &
rpcinfo -p

yet I get `rpc-server| No remote programs registered. rpc-server exited with code 0`

On Solaris, I enable nfs4 with those options vim /etc/default/nfs # Sets the minimum version of the NFS protocol that will be registered # and offered by the server. The default is 2. NFS_SERVER_VERSMIN=4 # Sets the maximum version of the NFS protocol that will be registered # and offered by the server. The default is 4. NFS_SERVER_VERSMAX=4 I try the same on Linux (the syntax is different) RPC_NFSD_OPTS="-N 2 -N 3" Nfs mount works on all hosts. But very strange thing happen with rpc On Linux rpcinfo -t 192.168.0.2 nfs 192.168.0.2: RPC: Program not registered On Solaris rpcinfo -t 192.168.201.3 nfs program 100003 version 4 ready and waiting Why rpc don't register nfs4 on Linux? Linux distro is Slackware 15.0 kernel version 6.11.10

My error is: mount.nfs4: access denied by server while mounting fileserver:/export/path/one My question is: >where would the detailed log information be on the server (under systemd)? More information: == I asked a similar question from the Ubuntu client perspective on AskUbuntu. My focus in this question is on the Arch Linux server. In particular, I am looking for logs on the server that will help me understand the problem. **Here's the background:** Our small LAN is running an Arch Linux NFS v4 file server. We have several clients running Ubuntu 15.10 and 16.04. We have one client running Ubuntu 14.04. The 14.04 client will not connect to the file server. The others all connect fine. The settings are the same on all clients. And all clients are listed in /etc/exports on the server. I need to find more detailed error information on the Arch linux server. However, journalctl does not show anything related to nfs and it does not contain any entries that are related to the nfs access denied errors. The 14.04 client can ping the fileserver as well as log in via SSH. The user name / ID as well as group match. (I'm using the same user account / uid on both client and server. It is uid 1000.) Even more info: ==

$ sudo mount -a (on client)
mount.nfs4: access denied by server while mounting fileserver:/export/path/one
mount.nfs4: access denied by server while mounting fileserver:/export/path/two

The client can ping the fileserver (and vice versa):

$ ping fileserver
PING fileserver (192.168.1.1) 56(84) bytes of data.
64 bytes from fileserver (192.168.1.1): icmp_seq=1 ttl=64 time=0.310 ms

The client successfully logs into the LAN-based fileserver:

$ ssh fileserver
Last login: Tue Aug 16 14:38:26 2016 from 192.168.1.2
[me@fileserver ~]$

The fileserver's mount export and rpcinfo are exposed to the client:

$ showmount -e fileserver    # on client
Export list for fileserver:
/export/path/one/ 192.168.1.2
/export/path/two/ 192.168.1.2,192.168.1.3

$ rpcinfo -p fileserver (on client)
    program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  58344  status
    100024    1   tcp  58561  status
    100005    1   udp  20048  mountd
    100005    1   tcp  20048  mountd
    100005    2   udp  20048  mountd
    100005    2   tcp  20048  mountd
    100005    3   udp  20048  mountd
    100005    3   tcp  20048  mountd
    100003    4   tcp   2049  nfs
    100003    4   udp   2049  nfs

This is the error when mounting the export directly:

$ sudo mount -vvv -t nfs4 fileserver:/export/path/one /path/one/

    mount: fstab path: "/etc/fstab"
    mount: mtab path:  "/etc/mtab"
    mount: lock path:  "/etc/mtab~"
    mount: temp path:  "/etc/mtab.tmp"
    mount: UID:        0
    mount: eUID:       0
    mount: spec:  "fileserver:/export/path/one"
    mount: node:  "/path/one/"
    mount: types: "nfs4"
    mount: opts:  "(null)"
    mount: external mount: argv = "/sbin/mount.nfs4"
    mount: external mount: argv[1]  = "fileserver:/export/path/one"
    mount: external mount: argv = "/path/one/"
    mount: external mount: argv = "-v"
    mount: external mount: argv = "-o"
    mount: external mount: argv = "rw"
    mount.nfs4: timeout set for Tue Aug 16 16:10:43 2016
    mount.nfs4: trying text-based options 'addr=192.168.1.1,clientaddr=192.168.1.2'
    mount.nfs4: mount(2): Permission denied
    mount.nfs4: access denied by server while mounting fileserver:/export/path/one

On my Debian box I am unable to mount an nfs share on my NAS. The local DNS server returns a link-local address for the NAS (because I have set it that way to prevent doing any configuration changes later when for instance my IPv6 prefix changes.)

# mount -t nfs -v nas:/volume2/nfs-share /mnt/nfs-share
mount.nfs: trying text-based options 'vers=4.2,addr=fe80::211:32ff:fec9:627a,clientaddr=::'
mount.nfs: mount(2): Invalid argument
mount.nfs: trying text-based options 'vers=4,minorversion=1,addr=fe80::211:32ff:fec9:627a,clientaddr=::'
mount.nfs: mount(2): Invalid argument
mount.nfs: trying text-based options 'vers=4,addr=fe80::211:32ff:fec9:627a,clientaddr=::'
mount.nfs: mount(2): Invalid argument
mount.nfs: trying text-based options 'addr=fe80::211:32ff:fec9:627a'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: portmap query failed: RPC: Remote system error - Invalid argument
mount.nfs: an incorrect mount option was specified

ping -6 works:

#ping -6 nas
PING nas(nas.localdomain.net (fe80::211:32ff:fec9:627a)) 56 data bytes
64 bytes from nas.localdomain.net (fe80::211:32ff:fec9:627a%ens3): icmp_seq=1 ttl=64 time=0.157 ms

So: DNS returns fe80::211:32ff:fec9:627a for host 'nas'. mount fails because the link-local address inputted in mount needs an interface identifier. This works:

# mount -t nfs -v [fe80::211:32ff:fec9:627a%ens3]:/volume2/nfs-share /mnt/nfs-share
mount.nfs: timeout set for Fri Jul  1 11:38:47 2022
mount.nfs: trying text-based options 'vers=4.2,addr=fe80::211:32ff:fec9:627a%ens3,clientaddr=fe80::1337'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'vers=4,minorversion=1,addr=fe80::211:32ff:fec9:627a%ens3,clientaddr=fe80::1337'

When I let DNS return the global IPv6 address for the nfs-share, it also mounts uneventfully. But I don't want to have any global IPv6 addresses in configuration files that might all be changed later when my ISP changes my IPv6 prefix. Same for rpcinfo:

# rpcinfo -p nas
nas: RPC: Remote system error - Invalid argument

# rpcinfo -p fe80::211:32ff:fec9:627a
fe80::211:32ff:fec9:627a: RPC: Remote system error - Invalid argument
# rpcinfo -p fe80::211:32ff:fec9:627a%ens3
   program vers proto   port  service
[...]
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
[...]

Obviously, I cannot set an interface identifier in DNS for the link-local address. -> Question: how can I make mount add the interface identifier ('%ens3') to the address for the nfs-share host?? [edit] Thank you A.B.! - The answer is to let the dhcp server give out ULA addresses to the hosts. In addition to any GUA addresses and link-local addresses. It's all very clear to me now and mount (a.o.) works fine also.

I'm working on an NFS solution for RHEL6.5 clients (all VMs) with RHEL6.5 and RHEL7 hosts. Currently, the RHEL7 host with RHEL6.5 clients works fine. The trouble is with the RHEL6.5 host. These problems might be down to aspects of the server I can't control, as the server has been having issues lately that it didn't last year. If you think that's the issue, please suggest ways I can prove this to my superiors, and begin the process of getting a new machine. The solution was initially being crafted to use NFSv4, which was going swell. The RHEL6.5 host, however, is not as keen as the RHEL7 host. Mounts succeed, but file access does not work, e.g. cp, less. In terminal, they hang. tail-ing the client's /var/log/messages shows state manager: lease expired failed on NFSv4 server nfs_master with error 10018. Per the standard, that error code is for NFS4ERR_RESOURCE, documented here . My attempt to resolve the resource issue was by increasing the number of nfsd processes via the command-line, and by setting the appropriate config in /etc/sysconfig/nfs. It didn't help. This issue also occurs if the exported directory is mounted on the NFS server itself. What is not shown in the logs for the host nor client is another error 10022, or at least I assume this is an NFSv4 error code. This is only viewable when tcpdump-ing the interface that the NFS communication is going over: IP test-host.nfs > test_client-1.3297002672: reply ok 52 getattr ERROR: unk 10022 If this error code is indeed an NFSv4 one, then it is for NFS4ERR_STALE_CLIENTID documented here . When the mount command is changed to set nfsvers=3, actions like cp are successful and generate no errors on the client nor the host. The first attempt will take a little long, 5 seconds maybe, then futures actions are much faster. At a time there will be at most four clients mounting the export and reading from it, and potentially the same file. So, my questions are: 1. What are the server-side resources being referred to by the NFS4ERR_RESOURCE description? 2. How do I resolve NFS4ERR_RESOURCE and NFS4ERR_STALE_CLIENTID errors? 3. Why is NFSv3 functioning as expected, but not NFSv4? nfs-utils version and release (for both clients and RHEL6.5 host): 1.2.3.39.el6 mount commands: - mount -n -t nfs -o ro,noexec,timeo=10,retrans=3,retry=0,soft,rsize=32768,intr,noatime - mount -n -t nfs -o nfsvers=3,ro,noexec,timeo=10,retrans=3,retry=0,soft,rsize=32768,intr,noatime **EDIT**: Our resolution for this issue was to fall back to NFSv3 protocol. Everything works just fine. I won't answer this question with a "just fall back to NFSv3", but this issue is probably too niche to ever see an answer.

I'm looking at lsof -i output on several Linux servers in our environment and finding that rpcbind opens the usual port 111 in both TCP and UDP protocols, but also opens port 873 UDP for no apparent reason. This is raising security flags because port 873 is assigned to rsyncd, and our policy requires rsync to use ssh transport (rsyncd performs no encryption and authentication is by trust relationships only). Usually when I'm suspicious of an RPC process, I look it up in rpcinfo -p to see which service is actually opening the port. However, on these servers, I only see port 111 for the portmapper and high-numbered ports for status and nlockmgr, with port 873 nowhere to be seen. I've seen a lot of bug reports out there (including RHEL: https://bugzilla.redhat.com/show_bug.cgi?id=103401 and kernel: https://patchwork.kernel.org/patch/10153769/) saying that the culprit is the bindresvport() function in glibc, but that function can't be changed there without massive breakage. I've seen three different solutions suggested: * RHEL provides a daemon called portreserve to pre-allocate these ports before rpcbind starts. This doesn't help me because it guarantees these ports are open, which we don't want for security reasons. * Debian and its progeny implement a configuration file at /etc/bindresvport.blacklist which would be ideal for our purposes, except for the fact it appears to be undocumented and subject to being stepped on by the distribution. * The nfs-utils package upstream of the distributions honors /etc/services and doesn't bind to registered ports. What I'm trying to nail down, though, is why would rpcbind be opening the extra port in the first place, and how can it be prevented? All I have checked so far seems to indicate that the port is assigned randomly at boot time, and restarting the server has been shown to push it to a different port, but that's no way to operate.

As indicated in https://en.wikipedia.org/wiki/Remote_procedure_call#Analogues , there are many implementations of RPC. Which RPC implementation does rpcbind apply to? I am using Lubuntu. Thanks.

$ rpcinfo program version netid address service owner 100000 4 tcp6 ::.0.111 portmapper superuser 100000 3 tcp6 ::.0.111 portmapper superuser 100000 4 udp6 ::.0.111 portmapper superuser 100000 3 udp6 ::.0.111 portmapper superuser 100000 4 tcp 0.0.0.0.0.111 portmapper superuser 100000 3 tcp 0.0.0.0.0.111 portmapper superuser 100000 2 tcp 0.0.0.0.0.111 portmapper superuser 100000 4 udp 0.0.0.0.0.111 portmapper superuser 100000 3 udp 0.0.0.0.0.111 portmapper superuser 100000 2 udp 0.0.0.0.0.111 portmapper superuser 100000 4 local /run/rpcbind.sock portmapper superuser 100000 3 local /run/rpcbind.sock portmapper superuser I think "address" shows the IPv6 address of a RPC service, according to https://unix.stackexchange.com/a/234158/674 . Does rpcinfo list the port number of a RPC service? How can I find it out?

$ rpcinfo program version netid address service owner 100000 4 tcp6 ::.0.111 portmapper superuser 100000 3 tcp6 ::.0.111 portmapper superuser 100000 4 udp6 ::.0.111 portmapper superuser 100000 3 udp6 ::.0.111 portmapper superuser 100000 4 tcp 0.0.0.0.0.111 portmapper superuser 100000 3 tcp 0.0.0.0.0.111 portmapper superuser 100000 2 tcp 0.0.0.0.0.111 portmapper superuser 100000 4 udp 0.0.0.0.0.111 portmapper superuser 100000 3 udp 0.0.0.0.0.111 portmapper superuser 100000 2 udp 0.0.0.0.0.111 portmapper superuser 100000 4 local /run/rpcbind.sock portmapper superuser 100000 3 local /run/rpcbind.sock portmapper superuser How can I get the manpage-like help information of a service? $ man portmapper No manual entry for portmapper How can I find out the actual program/executable/command name for a RPC service? For example portmapper isn't a command name for portmapper RPC service, otherwise man portmapper would likely works. Thanks.

I am trying to mount one of NFS volume exported from NetApp storage but getting below error. 10.242.12.24 is my NFS server. I am trying to mount on Suse 11.4 which is my NFS client. mount.nfs: trying text-based options 'hard,addr=10.242.12.24' mount.nfs: prog 100003, trying vers=3, prot=6 mount.nfs: trying 10.242.12.24 prog 100003 vers 3 prot TCP port 2049 mount.nfs: portmap query retrying: RPC: Timed out mount.nfs: prog 100003, trying vers=3, prot=17 mount.nfs: trying 10.242.12.24 prog 100003 vers 3 prot UDP port 2049 mount.nfs: portmap query failed: RPC: Timed out mount.nfs: mount to NFS server '10.242.12.24:/vol/v_fs0028' failed: timed out, giving up If run the below command, I get an error: iza0560:/tmp # rpcinfo -t 10.242.12.24 nfs rpcinfo: RPC: Timed out program 100003 version 0 is not available iza0560:/tmp # rpcinfo -u 10.242.12.24 nfs rpcinfo: RPC: Timed out program 100003 version 0 is not available iza0560:/tmp # iza0560:/tmp # rpcinfo -p 10.242.12.24 program vers proto port service 100011 1 udp 4049 rquotad 100024 1 tcp 4047 status 100024 1 udp 4047 status 100021 4 tcp 4045 nlockmgr 100021 3 tcp 4045 nlockmgr 100021 1 tcp 4045 nlockmgr 100021 4 udp 4045 nlockmgr 100021 3 udp 4045 nlockmgr 100021 1 udp 4045 nlockmgr 100005 3 tcp 4046 mountd 100003 3 tcp 2049 nfs 100005 2 tcp 4046 mountd 100005 1 tcp 4046 mountd 100003 2 tcp 2049 nfs 100005 3 udp 4046 mountd 100003 3 udp 2049 nfs 100005 2 udp 4046 mountd 100005 1 udp 4046 mountd 100003 2 udp 2049 nfs 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper Telnet over port 111, 2049 and others of NFS server are working.

I'm using the kernel command line parameter ipv6.disable=1 in my boot loader (systemd boot) to disable IPv6. However, with that option, I now get these errors in the journal after booting up. Jul 09 02:38:48 arch rpcbind: cannot create socket for udp6 Jul 09 02:38:48 arch rpcbind: cannot create socket for tcp6 Jul 09 02:38:48 arch rpc.statd: Failed to create listener xprt (statd, 1, udp6) Jul 09 02:38:48 arch rpc.mountd: Could not make a socket: (97) Address family not supported by protocol This is Arch Linux 4.14.53-1-lts #1 SMP Tue Jul 3 16:27:18 CEST 2018 x86_64 GNU/Linux What are the consequences of these errors and how do I resolve this while keeping IPv6 disabled? More info: rpcinfo -p program vers proto port service 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100000 4 udp 111 portmapper 100000 3 udp 111 portmapper 100000 2 udp 111 portmapper 100005 1 udp 20048 mountd 100005 1 tcp 20048 mountd 100005 2 udp 20048 mountd 100024 1 udp 48386 status 100005 2 tcp 20048 mountd 100024 1 tcp 47193 status 100005 3 udp 20048 mountd 100005 3 tcp 20048 mountd 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100227 3 tcp 2049 nfs_acl 100021 1 udp 54818 nlockmgr 100021 3 udp 54818 nlockmgr 100021 4 udp 54818 nlockmgr 100021 1 tcp 42833 nlockmgr 100021 3 tcp 42833 nlockmgr 100021 4 tcp 42833 nlockmgr

My /usr/include contains several files with the .x file extension, such as /usr/include/rpcsvc/rquota.x. They seem like C sources (running file /usr/include/rpcsvc/rquota.x results in C source, ASCII text), but they are not valid C (e.g. program and version seem keywords). What are they exactly? It's hard to google given the short extension, and some websites are just wrong/incomplete (e.g. [Wikipedia](https://en.wikipedia.org/wiki/.x) says "old DirectX files").

I have a dns server running bind without iptables configuration. Running some scanners with nmap, I found that no root in some high moments ports are open but soon close, and stay in that loop. When I walk with root these ports do not appear at any time. Here is an output of nmap: Host is up (0.00022s latency). Scanned at 2016-09-10 01:04:48 UTC for 0s Not shown: 64996 closed ports PORT STATE SERVICE 22/tcp open ssh 53/tcp open domain 111/tcp open rpcbind 52347/tcp open unknown And a moment later ... Host is up (0.00022s latency). Scanned at 2016-09-10 01:04:49 UTC for 1s Not shown: 64994 closed ports PORT STATE SERVICE 22/tcp open ssh 53/tcp open domain 111/tcp open rpcbind 38248/tcp open unknown 52347/tcp open unknown 55806/tcp open unknown Output of netstat -ltnp Conexões Internet Ativas (sem os servidores) Proto Recv-Q Send-Q Endereço Local Endereço Remoto Estado PID/Program name tcp 0 0 127.0.0.1:953 0.0.0.0:* OUÇA 7209/named tcp 0 0 0.0.0.0:52347 0.0.0.0:* OUÇA 902/rpc.statd tcp 0 0 0.0.0.0:111 0.0.0.0:* OUÇA 888/rpcbind tcp 0 0 XXX.XX.XX.X:53 0.0.0.0:* OUÇA 7209/named tcp 0 0 XXX.XXX.XX.X:53 0.0.0.0:* OUÇA 7209/named tcp 0 0 127.0.0.1:53 0.0.0.0:* OUÇA 7209/named tcp 0 0 0.0.0.0:22 0.0.0.0:* OUÇA 935/sshd tcp 0 0 127.0.0.1:631 0.0.0.0:* OUÇA 1258/cupsd tcp6 0 0 :::48323 :::* OUÇA 902/rpc.statd tcp6 0 0 :::111 :::* OUÇA 888/rpcbind tcp6 0 0 :::22 :::* OUÇA 935/sshd tcp6 0 0 ::1:631 :::* OUÇA 1258/cupsd My system is Linux lDebian13 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u1 (2016-09-03) x86_64 GNU/Linux What is it these ports? will bug? is a backdoor? how can I get information from them?