From Newsgroup: alt.os.linux.mint

Ever since I backed up to a second machine I had been using samba.
As a result I mounted using cifs and included username, password and
domain in the command line.

I no longer need Samba and so reduced my mount statement to a minimal:

$ sudo mount -t ext4 -o rw //192.168.1.120/backups/data/ /mnt/monty/data

That doesn't work because the menu structure is:

/home/alan
/backups/alan
/data

So //192.168.1.120 will be pointing at /home/alan when I need it at /home or /home/backups

Any suggestions?

Alan

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

Sorry the draft went by accident. So,

Ever since I backed up to a second machine I had been using samba.
As a result I mounted using cifs and included username, password and
domain in the command line.

I no longer need Samba and so reduced my mount statement to a minimal:

$ sudo mount -t nfs -o rw //192.168.1.120:/home/backups/data/ /mnt/monty/data

The menu structure is:

/home/alan
/backups/alan
/data

When I ran that it returned:

mount.nfs: Failed to resolve server //192.168.1.120: Name or service not known

Any suggestions?

Alan

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On Thu, 9/4/2025 10:41 AM, pinnerite wrote:

Sorry the draft went by accident. So,

Ever since I backed up to a second machine I had been using samba.
As a result I mounted using cifs and included username, password and
domain in the command line.

I no longer need Samba and so reduced my mount statement to a minimal:

$ sudo mount -t nfs -o rw //192.168.1.120:/home/backups/data/ /mnt/monty/data

The menu structure is:

/home/alan
/backups/alan
/data

When I ran that it returned:

mount.nfs: Failed to resolve server //192.168.1.120: Name or service not known

Any suggestions?

Alan

"Use the following command to mount an NFS share on a client:

mount <nfs_server_ip_or_hostname>:/<exported_share> <mount point>
"

The Redhat example in that case, is not nearly explicit enough about syntax. Let us try another of their examples, where they stuff a line of text into /etc/fstab file.

"Procedure

1. Edit the /etc/fstab file and add a line for the share that you want to mount:

<nfs_server_ip_or_hostname>:/<exported_share> <mount point> nfs default 0 0

For example, to mount the /nfs/projects share from the
server.example.com NFS server to /home enter:

server.example.com:/nfs/projects /home nfs defaults 0 0

Yes, they also have a typo in "default" versus "defaults". You can tell an AI does not write these articles, when things like that happen.

Notice there is no trailing slash, on the item as well.

So anyway, the point of this expose is that the syntax of NFS mounts is
not the same as SMB/CIFS examples, and you should be careful to not
copy the "style" of the previous thing you were doing, into the current attempt.

Paul


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On 2025-09-04, pinnerite wrote:

Ever since I backed up to a second machine I had been using samba.
As a result I mounted using cifs and included username, password and
domain in the command line.

I no longer need Samba and so reduced my mount statement to a minimal:

$ sudo mount -t ext4 -o rw //192.168.1.120/backups/data/ /mnt/monty/data

That doesn't work because [...]

it's completely invalid for an ext4 filesystem, among other things.

I'm going to assume this is an NFS mount, in which case

mount -t nfs 192.168.1.120:/backups/data /mnt/monty/data

assuming, of course, "/backups/data" is the correct path on the remote
machine.
--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On 2025-09-04, pinnerite <pinnerite@gmail.com> wrote:

Sorry the draft went by accident. So,

Ever since I backed up to a second machine I had been using samba.
As a result I mounted using cifs and included username, password and
domain in the command line.

I no longer need Samba and so reduced my mount statement to a minimal:

$ sudo mount -t nfs -o rw //192.168.1.120:/home/backups/data/ /mnt/monty/data

The menu structure is:

/home/alan
/backups/alan
/data

When I ran that it returned:

mount.nfs: Failed to resolve server //192.168.1.120: Name or service not known

Any suggestions?

Is the nfs server active?



$ sudo mount -t nfs -o rw //192.168.1.120:/home/backups/data/ /mnt/monty/data

I would try

sudo mount -t nfs 192.168.1.120:/home/backups/data /mnt/minty/data

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On Thu, 4 Sep 2025 19:36:44 -0000 (UTC)
Dan Purgert <dan@djph.net> wrote:

On 2025-09-04, pinnerite wrote:

Ever since I backed up to a second machine I had been using samba.
As a result I mounted using cifs and included username, password and
domain in the command line.

I no longer need Samba and so reduced my mount statement to a minimal:

$ sudo mount -t ext4 -o rw //192.168.1.120/backups/data/ /mnt/monty/data

That doesn't work because [...]

it's completely invalid for an ext4 filesystem, among other things.

I'm going to assume this is an NFS mount, in which case

mount -t nfs 192.168.1.120:/backups/data /mnt/monty/data

assuming, of course, "/backups/data" is the correct path on the remote machine.

The nfs-kernel-server had not been installed on the local machine but
was on the remote(?) Now remedied.

mount -t nfs 192.168.1.120:/backups/data /mnt/monty/data is correct but
it just times out.

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On 2025-09-05, pinnerite wrote:

On Thu, 4 Sep 2025 19:36:44 -0000 (UTC)
Dan Purgert <dan@djph.net> wrote:

On 2025-09-04, pinnerite wrote:

Ever since I backed up to a second machine I had been using samba.
As a result I mounted using cifs and included username, password and
domain in the command line.

I no longer need Samba and so reduced my mount statement to a minimal:

$ sudo mount -t ext4 -o rw //192.168.1.120/backups/data/ /mnt/monty/data >> >
That doesn't work because [...]

it's completely invalid for an ext4 filesystem, among other things.

I'm going to assume this is an NFS mount, in which case

mount -t nfs 192.168.1.120:/backups/data /mnt/monty/data

assuming, of course, "/backups/data" is the correct path on the remote
machine.

The nfs-kernel-server had not been installed on the local machine but
was on the remote(?) Now remedied.

You only need "nfs-kernel-server" on the machine(s) that are acting as
servers. Clients only need "nfs-common" (or something close to that)

mount -t nfs 192.168.1.120:/backups/data /mnt/monty/data is correct but
it just times out.

"just times out" sounds like either

(A) the machine "192.168.1.120" is not actually running an NFS server OR
(B) the firewall on that machine is blocking the connection.
--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On Fri, 5 Sep 2025 11:58:51 -0000 (UTC)
Dan Purgert <dan@djph.net> wrote:

On 2025-09-05, pinnerite wrote:

On Thu, 4 Sep 2025 19:36:44 -0000 (UTC)
Dan Purgert <dan@djph.net> wrote:

On 2025-09-04, pinnerite wrote:

Ever since I backed up to a second machine I had been using samba.
As a result I mounted using cifs and included username, password and
domain in the command line.

I no longer need Samba and so reduced my mount statement to a minimal: >> >
$ sudo mount -t ext4 -o rw //192.168.1.120/backups/data/ /mnt/monty/data

That doesn't work because [...]

it's completely invalid for an ext4 filesystem, among other things.

I'm going to assume this is an NFS mount, in which case

mount -t nfs 192.168.1.120:/backups/data /mnt/monty/data

assuming, of course, "/backups/data" is the correct path on the remote
machine.

The nfs-kernel-server had not been installed on the local machine but
was on the remote(?) Now remedied.

You only need "nfs-kernel-server" on the machine(s) that are acting as servers. Clients only need "nfs-common" (or something close to that)

mount -t nfs 192.168.1.120:/backups/data /mnt/monty/data is correct but
it just times out.

"just times out" sounds like either

(A) the machine "192.168.1.120" is not actually running an NFS server OR
(B) the firewall on that machine is blocking the connection.

It is almost working but only after I recruited ChatGPT. It took a long
time to pin it down. I have kept the whole sequence with multiple
duplicates and blind alleys. I will tidy it up and post it once I have
overcome the remaining issues.

Thanks for your help.

Alan




--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.mint

On Fri, 5 Sep 2025 11:58:51 -0000 (UTC), Dan Purgert wrote:

"just times out" sounds like either

(A) the machine "192.168.1.120" is not actually running an NFS server OR
(B) the firewall on that machine is blocking the connection.

NFS is an application built on SunRPC, and SunRPC communicates on port
111, as I recall.
--- Synchronet 3.21a-Linux NewsLink 1.2