Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #66781 > unrolled thread

Here's One - NFS - Mounting Over Share = Nada

Back to article view | Back to comp.os.linux.misc

Contents

  Here's One - NFS - Mounting Over Share = Nada c186282 <c186282@nnada.net> - 2025-04-01 21:29 -0400
    Re: Here's One - NFS - Mounting Over Share = Nada "Carlos E.R." <robin_listas@es.invalid> - 2025-04-02 12:35 +0200
      Re: Here's One - NFS - Mounting Over Share = Nada The Natural Philosopher <tnp@invalid.invalid> - 2025-04-02 11:48 +0100
        Re: Here's One - NFS - Mounting Over Share = Nada "Carlos E.R." <robin_listas@es.invalid> - 2025-04-02 13:18 +0200
          Re: Here's One - NFS - Mounting Over Share = Nada The Natural Philosopher <tnp@invalid.invalid> - 2025-04-02 18:04 +0100
            Re: Here's One - NFS - Mounting Over Share = Nada c186282 <c186282@nnada.net> - 2025-04-03 05:51 -0400
              Re: Here's One - NFS - Mounting Over Share = Nada The Natural Philosopher <tnp@invalid.invalid> - 2025-04-03 11:08 +0100
              Re: Here's One - NFS - Mounting Over Share = Nada "Carlos E.R." <robin_listas@es.invalid> - 2025-04-03 14:07 +0200
                Re: Here's One - NFS - Mounting Over Share = Nada c186282 <c186282@nnada.net> - 2025-04-03 11:27 -0400
                  Re: Here's One - NFS - Mounting Over Share = Nada Ralf Fassel <ralfixx@gmx.de> - 2025-04-03 18:36 +0200
                    Re: Here's One - NFS - Mounting Over Share = Nada The Natural Philosopher <tnp@invalid.invalid> - 2025-04-03 18:09 +0100
                      Re: Here's One - NFS - Mounting Over Share = Nada c186282 <c186282@nnada.net> - 2025-04-03 16:42 -0400
                    Re: Here's One - NFS - Mounting Over Share = Nada c186282 <c186282@nnada.net> - 2025-04-03 15:27 -0400
                  Re: Here's One - NFS - Mounting Over Share = Nada The Natural Philosopher <tnp@invalid.invalid> - 2025-04-03 18:08 +0100
                    Re: Here's One - NFS - Mounting Over Share = Nada "Carlos E.R." <robin_listas@es.invalid> - 2025-04-03 20:48 +0200
                      Re: Here's One - NFS - Mounting Over Share = Nada c186282 <c186282@nnada.net> - 2025-04-03 15:49 -0400
    Re: Here's One - NFS - Mounting Over Share = Nada vallor <vallor@cultnix.org> - 2025-04-02 10:49 +0000
      Re: Here's One - NFS - Mounting Over Share = Nada c186282 <c186282@nnada.net> - 2025-04-02 07:12 -0400
      Re: Here's One - NFS - Mounting Over Share = Nada "Carlos E.R." <robin_listas@es.invalid> - 2025-04-02 13:14 +0200
        Re: Here's One - NFS - Mounting Over Share = Nada c186282 <c186282@nnada.net> - 2025-04-02 07:39 -0400
          Re: Here's One - NFS - Mounting Over Share = Nada "Carlos E.R." <robin_listas@es.invalid> - 2025-04-02 14:19 +0200
            Re: Here's One - NFS - Mounting Over Share = Nada c186282 <c186282@nnada.net> - 2025-04-02 08:38 -0400
              Re: Here's One - NFS - Mounting Over Share = Nada "Carlos E.R." <robin_listas@es.invalid> - 2025-04-02 15:30 +0200
        Re: Here's One - NFS - Mounting Over Share = Nada vallor <vallor@cultnix.org> - 2025-04-02 11:40 +0000
          Re: Here's One - NFS - Mounting Over Share = Nada c186282 <c186282@nnada.net> - 2025-04-02 08:08 -0400
            Re: Here's One - NFS - Mounting Over Share = Nada "Carlos E.R." <robin_listas@es.invalid> - 2025-04-02 14:25 +0200
          Re: Here's One - NFS - Mounting Over Share = Nada "Carlos E.R." <robin_listas@es.invalid> - 2025-04-02 14:15 +0200
            Re: Here's One - NFS - Mounting Over Share = Nada Computer Nerd Kev <not@telling.you.invalid> - 2025-04-03 16:40 +1000
              Re: Here's One - NFS - Mounting Over Share = Nada c186282 <c186282@nnada.net> - 2025-04-03 06:19 -0400
                Re: Here's One - NFS - Mounting Over Share = Nada The Natural Philosopher <tnp@invalid.invalid> - 2025-04-03 12:03 +0100
                  Re: Here's One - NFS - Mounting Over Share = Nada c186282 <c186282@nnada.net> - 2025-04-03 07:27 -0400
                    Re: Here's One - NFS - Mounting Over Share = Nada The Natural Philosopher <tnp@invalid.invalid> - 2025-04-03 12:38 +0100

Page 2 of 2 — ← Prev page 1 [2]

#66801

On 2025-04-02 13:39, c186282 wrote:
> On 4/2/25 7:14 AM, Carlos E.R. wrote:
>> On 2025-04-02 12:49, vallor wrote:
>>> On Tue, 1 Apr 2025 21:29:48 -0400, c186282 <c186282@nnada.net> wrote in
>>> <UQ-dndQV6amaDnH6nZ2dnZfqnPednZ2d@giganews.com>:
>>>
>>>> Here's an interesting problem ....
>>>>
>>>> I re-mount USB drives onto NFS share points. The problem is that NFS
>>>> doesn't SEE that - it only sees the previously empty dir instead.
>>>> Add a tag file to that dir and that's ALL you will see in the share on
>>>> another PC.
>>>>
>>>> Tried variations of exportfs ... including the '-r' and '-au' then '-a'
>>>> AFTER doing the mount. Sorry, the clients can't see the mount. The NFS
>>>> stuff seems to cut in very early - before the USB re-mounts (done
>>>> @reboot). If you look on the host machine you DO see the USB drives, 
>>>> but
>>>> NEVER over the NFS share.
>>>>
>>>> Why re-mount the USBs ? Because you can't always rely on Linux to mount
>>>> them in the same order, used to be even the same place.
>>>> '/media/<user>/whatever' seems hard-wired these days, but with multiple
>>>> USB drives you still can't count on drive 1 being the drive 1 in
>>>> /media/<user>. Kinda depends on which comes online first.
>>>> Naming the drives helps, but even then.
>>>>
>>>> And no, symlinks to some other mount point don't work ... NFS just
>>>> shares a link to nowhere on the clients. 'hard' links ???
>>>>
>>>> Have ONE share that's not a re-mounted anything - THAT always shows
>>>> perfectly on the clients. Weird thing, somehow, at one point I DID get
>>>> it to work - but not sure HOW. Just commented-out the old NFS and fstab
>>>> stuff, so I've been able to re-try, but now none work. Set 
>>>> everything to
>>>> 775 or 777 for development work, but that doesn't help.
>>>>
>>>> SAMBA - this sort of thing works fine, but I've had horrible probs with
>>>> SAMBA with the latest distros, ALWAYS intractable permissions issues no
>>>> matter the tweaks, hence using NFS.
>>>>
>>>> So ... any insights on how to get NFS to "see" whatever IS mounted to
>>>> the share point AT THE MOMENT ???
>>>>
>>>> Oh, latest MX Linux.
>>>
>>> Take a look at "man exports" under the "nohide" option.
>>
>> Ah, yes.
>>
>> Last line says "not if you use NFSv4". The hiding doesn't happen with 
>> version 4.
>>
>> Reminds me of something. How does one know what version is actually used?
> 
> 
>    /var/libs/nfs/etab reads "NFS4"

No such file here, not even the directory. It is "/var/lib/nfs/etab" here.

But no, the version is not there:

/data/hoard_1	192.168.2.0/24(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no_all_squash,subtree_check,secure_locks,acl,no_pnfs,fsid=10,anonuid=65534,anongid=65534,sec=sys,rw,secure,no_root_squash,no_all_squash)

> 
>    But remounts to the shared dir still do
>    not register.
> 
>    I'd LIKE NFS to reflect WHATEVER THE HELL I currently
>    have mounted to that share dir.
> 
>    Or maybe it just CAN'T ??? There ARE reasons I stuck
>    with SAMBA so long ... it (used to) Just Work.


As I said, I restart the server. Or perhaps, "exportfs -r".


Actually, I have a server machine with external disks, and they are just mounted and exported properly, no issues.

Except that if the disk is not mounted, nfs doesn't start.


-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#66803

On 4/2/25 8:19 AM, Carlos E.R. wrote:
> On 2025-04-02 13:39, c186282 wrote:
>> On 4/2/25 7:14 AM, Carlos E.R. wrote:
>>> On 2025-04-02 12:49, vallor wrote:
>>>> On Tue, 1 Apr 2025 21:29:48 -0400, c186282 <c186282@nnada.net> wrote in
>>>> <UQ-dndQV6amaDnH6nZ2dnZfqnPednZ2d@giganews.com>:
>>>>
>>>>> Here's an interesting problem ....
>>>>>
>>>>> I re-mount USB drives onto NFS share points. The problem is that NFS
>>>>> doesn't SEE that - it only sees the previously empty dir instead.
>>>>> Add a tag file to that dir and that's ALL you will see in the share on
>>>>> another PC.
>>>>>
>>>>> Tried variations of exportfs ... including the '-r' and '-au' then 
>>>>> '-a'
>>>>> AFTER doing the mount. Sorry, the clients can't see the mount. The NFS
>>>>> stuff seems to cut in very early - before the USB re-mounts (done
>>>>> @reboot). If you look on the host machine you DO see the USB 
>>>>> drives, but
>>>>> NEVER over the NFS share.
>>>>>
>>>>> Why re-mount the USBs ? Because you can't always rely on Linux to 
>>>>> mount
>>>>> them in the same order, used to be even the same place.
>>>>> '/media/<user>/whatever' seems hard-wired these days, but with 
>>>>> multiple
>>>>> USB drives you still can't count on drive 1 being the drive 1 in
>>>>> /media/<user>. Kinda depends on which comes online first.
>>>>> Naming the drives helps, but even then.
>>>>>
>>>>> And no, symlinks to some other mount point don't work ... NFS just
>>>>> shares a link to nowhere on the clients. 'hard' links ???
>>>>>
>>>>> Have ONE share that's not a re-mounted anything - THAT always shows
>>>>> perfectly on the clients. Weird thing, somehow, at one point I DID get
>>>>> it to work - but not sure HOW. Just commented-out the old NFS and 
>>>>> fstab
>>>>> stuff, so I've been able to re-try, but now none work. Set 
>>>>> everything to
>>>>> 775 or 777 for development work, but that doesn't help.
>>>>>
>>>>> SAMBA - this sort of thing works fine, but I've had horrible probs 
>>>>> with
>>>>> SAMBA with the latest distros, ALWAYS intractable permissions 
>>>>> issues no
>>>>> matter the tweaks, hence using NFS.
>>>>>
>>>>> So ... any insights on how to get NFS to "see" whatever IS mounted to
>>>>> the share point AT THE MOMENT ???
>>>>>
>>>>> Oh, latest MX Linux.
>>>>
>>>> Take a look at "man exports" under the "nohide" option.
>>>
>>> Ah, yes.
>>>
>>> Last line says "not if you use NFSv4". The hiding doesn't happen with 
>>> version 4.
>>>
>>> Reminds me of something. How does one know what version is actually 
>>> used?
>>
>>
>>    /var/libs/nfs/etab reads "NFS4"
> 
> No such file here, not even the directory. It is "/var/lib/nfs/etab" here.
> 
> But no, the version is not there:
> 
> /data/hoard_1    

   You FIRST have to set up NFS and then edit /etc/exports and
   finally "exportfs -a". THEN the file will be in var/libs/nfs.
   That's what NFS really uses.

> 192.168.2.0/24(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no_all_squash,subtree_check,secure_locks,acl,no_pnfs,fsid=10,anonuid=65534,anongid=65534,sec=sys,rw,secure,no_root_squash,no_all_squash) 
> 
> 
>>
>>    But remounts to the shared dir still do
>>    not register.
>>
>>    I'd LIKE NFS to reflect WHATEVER THE HELL I currently
>>    have mounted to that share dir.
>>
>>    Or maybe it just CAN'T ??? There ARE reasons I stuck
>>    with SAMBA so long ... it (used to) Just Work.
> 
> 
> As I said, I restart the server. Or perhaps, "exportfs -r".

   Sorry, restarts do NOT work.

   It's kind of a TIMING problem.

   NFS seems to start up VERY early - and then fixates
   on whatever it finds. Re-mounts to the share dir
   come LATER and are NOT seen by NFS.

> 
> Actually, I have a server machine with external disks, and they are just 
> mounted and exported properly, no issues.
> 
> Except that if the disk is not mounted, nfs doesn't start.

   Well, you got lucky.

   I'm not being so lucky.

   The share dirs DO exist, and NFS finds them, but
   NFS is not flexible about what's mounted there
   AT THE MOMENT.

   Being able to mount and re-mount and share
   whatever the hell is mounted NOW can be VERY
   useful and flexible. Should be SOME way to
   make NFS re-eval what's there. Been at this
   for days now and have 20 years of Linux
   experience - Slack and RH on FLOPPIES ...

   But I always figured NFS was ancient crap ...

   Anyway, today, I'm gonna try a HARD link to
   a 3rd dir where I can mount/re-mount as
   needed. Perhaps THAT link will work ?

[toc] | [prev] | [next] | [standalone]

#66804

On 2025-04-02 14:38, c186282 wrote:
> On 4/2/25 8:19 AM, Carlos E.R. wrote:
>> On 2025-04-02 13:39, c186282 wrote:
>>> On 4/2/25 7:14 AM, Carlos E.R. wrote:
>>>> On 2025-04-02 12:49, vallor wrote:
>>>>> On Tue, 1 Apr 2025 21:29:48 -0400, c186282 <c186282@nnada.net> 
>>>>> wrote in
>>>>> <UQ-dndQV6amaDnH6nZ2dnZfqnPednZ2d@giganews.com>:
>>>>>

...

>>>>>> So ... any insights on how to get NFS to "see" whatever IS mounted to
>>>>>> the share point AT THE MOMENT ???
>>>>>>
>>>>>> Oh, latest MX Linux.
>>>>>
>>>>> Take a look at "man exports" under the "nohide" option.
>>>>
>>>> Ah, yes.
>>>>
>>>> Last line says "not if you use NFSv4". The hiding doesn't happen 
>>>> with version 4.
>>>>
>>>> Reminds me of something. How does one know what version is actually 
>>>> used?
>>>
>>>
>>>    /var/libs/nfs/etab reads "NFS4"
>>
>> No such file here, not even the directory. It is "/var/lib/nfs/etab" 
>> here.
>>
>> But no, the version is not there:
>>
>> /data/hoard_1 
> 
>    You FIRST have to set up NFS and then edit /etc/exports and
>    finally "exportfs -a". THEN the file will be in var/libs/nfs.
>    That's what NFS really uses.

nfs is setup and running and working fine. That directory does not exist 
here, it is "/var/lib/nfs/etab" here. Not "libs" but "lib"

Please pay attention.

> 
>> 192.168.2.0/24(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no_all_squash,subtree_check,secure_locks,acl,no_pnfs,fsid=10,anonuid=65534,anongid=65534,sec=sys,rw,secure,no_root_squash,no_all_squash)
>>
>>>
>>>    But remounts to the shared dir still do
>>>    not register.
>>>
>>>    I'd LIKE NFS to reflect WHATEVER THE HELL I currently
>>>    have mounted to that share dir.
>>>
>>>    Or maybe it just CAN'T ??? There ARE reasons I stuck
>>>    with SAMBA so long ... it (used to) Just Work.
>>
>>
>> As I said, I restart the server. Or perhaps, "exportfs -r".
> 
>    Sorry, restarts do NOT work.

Works for me, what can I say.


-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#66797

On Wed, 2 Apr 2025 13:14:44 +0200, "Carlos E.R." <robin_listas@es.invalid>
wrote in <4qivblx7ff.ln2@Telcontar.valinor>:

> On 2025-04-02 12:49, vallor wrote:
>> On Tue, 1 Apr 2025 21:29:48 -0400, c186282 <c186282@nnada.net> wrote in
>> <UQ-dndQV6amaDnH6nZ2dnZfqnPednZ2d@giganews.com>:
>> 
>>> Here's an interesting problem ....
>>>
>>> I re-mount USB drives onto NFS share points. The problem is that NFS
>>> doesn't SEE that - it only sees the previously empty dir instead.
>>> Add a tag file to that dir and that's ALL you will see in the share on
>>> another PC.
>>>
>>> Tried variations of exportfs ... including the '-r' and '-au' then
>>> '-a' AFTER doing the mount. Sorry, the clients can't see the mount.
>>> The NFS stuff seems to cut in very early - before the USB re-mounts
>>> (done @reboot). If you look on the host machine you DO see the USB
>>> drives, but NEVER over the NFS share.
>>>
>>> Why re-mount the USBs ? Because you can't always rely on Linux to
>>> mount them in the same order, used to be even the same place.
>>> '/media/<user>/whatever' seems hard-wired these days, but with
>>> multiple USB drives you still can't count on drive 1 being the drive 1
>>> in /media/<user>. Kinda depends on which comes online first.
>>> Naming the drives helps, but even then.
>>>
>>> And no, symlinks to some other mount point don't work ... NFS just
>>> shares a link to nowhere on the clients. 'hard' links ???
>>>
>>> Have ONE share that's not a re-mounted anything - THAT always shows
>>> perfectly on the clients. Weird thing, somehow, at one point I DID get
>>> it to work - but not sure HOW. Just commented-out the old NFS and
>>> fstab stuff, so I've been able to re-try, but now none work. Set
>>> everything to 775 or 777 for development work, but that doesn't help.
>>>
>>> SAMBA - this sort of thing works fine, but I've had horrible probs
>>> with SAMBA with the latest distros, ALWAYS intractable permissions
>>> issues no matter the tweaks, hence using NFS.
>>>
>>> So ... any insights on how to get NFS to "see" whatever IS mounted to
>>> the share point AT THE MOMENT ???
>>>
>>> Oh, latest MX Linux.
>> 
>> Take a look at "man exports" under the "nohide" option.
> 
> Ah, yes.
> 
> Last line says "not if you use NFSv4". The hiding doesn't happen with
> version 4.
> 
> Reminds me of something. How does one know what version is actually
> used?

use "mount | grep mountpoint", the version will be in there as "vers=",
and also the type, e.g.:

$ mount | grep /nfs/ds
192.168.23.12:/volume1/ds on /nfs/ds type nfs4
(rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,
hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.23.254,
local_lock=none,addr=192.168.23.12)

(I've wrapped the line for posting on Usenet.)

-- 
-v System76 Thelio Mega v1.1 x86_64 NVIDIA RTX 3090 Ti
   OS: Linux 6.14.0 Release: Mint 22.1 Mem: 258G
   "The world is so big and so global now."

[toc] | [prev] | [next] | [standalone]

#66798

On 4/2/25 7:40 AM, vallor wrote:
> On Wed, 2 Apr 2025 13:14:44 +0200, "Carlos E.R." <robin_listas@es.invalid>
> wrote in <4qivblx7ff.ln2@Telcontar.valinor>:
> 
>> On 2025-04-02 12:49, vallor wrote:
>>> On Tue, 1 Apr 2025 21:29:48 -0400, c186282 <c186282@nnada.net> wrote in
>>> <UQ-dndQV6amaDnH6nZ2dnZfqnPednZ2d@giganews.com>:
>>>
>>>> Here's an interesting problem ....
>>>>
>>>> I re-mount USB drives onto NFS share points. The problem is that NFS
>>>> doesn't SEE that - it only sees the previously empty dir instead.
>>>> Add a tag file to that dir and that's ALL you will see in the share on
>>>> another PC.
>>>>
>>>> Tried variations of exportfs ... including the '-r' and '-au' then
>>>> '-a' AFTER doing the mount. Sorry, the clients can't see the mount.
>>>> The NFS stuff seems to cut in very early - before the USB re-mounts
>>>> (done @reboot). If you look on the host machine you DO see the USB
>>>> drives, but NEVER over the NFS share.
>>>>
>>>> Why re-mount the USBs ? Because you can't always rely on Linux to
>>>> mount them in the same order, used to be even the same place.
>>>> '/media/<user>/whatever' seems hard-wired these days, but with
>>>> multiple USB drives you still can't count on drive 1 being the drive 1
>>>> in /media/<user>. Kinda depends on which comes online first.
>>>> Naming the drives helps, but even then.
>>>>
>>>> And no, symlinks to some other mount point don't work ... NFS just
>>>> shares a link to nowhere on the clients. 'hard' links ???
>>>>
>>>> Have ONE share that's not a re-mounted anything - THAT always shows
>>>> perfectly on the clients. Weird thing, somehow, at one point I DID get
>>>> it to work - but not sure HOW. Just commented-out the old NFS and
>>>> fstab stuff, so I've been able to re-try, but now none work. Set
>>>> everything to 775 or 777 for development work, but that doesn't help.
>>>>
>>>> SAMBA - this sort of thing works fine, but I've had horrible probs
>>>> with SAMBA with the latest distros, ALWAYS intractable permissions
>>>> issues no matter the tweaks, hence using NFS.
>>>>
>>>> So ... any insights on how to get NFS to "see" whatever IS mounted to
>>>> the share point AT THE MOMENT ???
>>>>
>>>> Oh, latest MX Linux.
>>>
>>> Take a look at "man exports" under the "nohide" option.
>>
>> Ah, yes.
>>
>> Last line says "not if you use NFSv4". The hiding doesn't happen with
>> version 4.
>>
>> Reminds me of something. How does one know what version is actually
>> used?
> 
> use "mount | grep mountpoint", the version will be in there as "vers=",
> and also the type, e.g.:
> 
> $ mount | grep /nfs/ds
> 192.168.23.12:/volume1/ds on /nfs/ds type nfs4
> (rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,
> hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.23.254,
> local_lock=none,addr=192.168.23.12)
> 
> (I've wrapped the line for posting on Usenet.)


   Simply cat /var/libs/nfs/etab and you'll see the NFS
   version, simple pattern match.

   In my case, latest MX, NFS4.

   Somehow this seems to revolve around UPDATES to
   the stated NFS share mount point. It does NOT
   keep up with the changes, despite attempts to
   reload/re-init the share. Tried a LOT of tricks
   at this point.

   Simple goal - I want NFS to share what's mounted
   to the stated point ALL THE TIME, not JUST five
   microseconds after boot-up. MAY want scripts to
   change what's mounted there a number of times
   per day for max flexibility.

   CAN NFS *do* that without horrific complications ?

   If not, well, will HAVE to solve those recent
   SAMBA permissions issues .......

[toc] | [prev] | [next] | [standalone]

#66802

On 2025-04-02 14:08, c186282 wrote:

> 
>    Simple goal - I want NFS to share what's mounted
>    to the stated point ALL THE TIME, not JUST five
>    microseconds after boot-up. MAY want scripts to
>    change what's mounted there a number of times
>    per day for max flexibility.
> 
>    CAN NFS *do* that without horrific complications ?

I am doing it. But it is fixed mounts.

It is an encrypted disk.


Isengard:~ # grep hoard_1 /etc/crypttab
cr_hoard_1	/dev/disk/by-partlabel/hoard_1_raw	/Keys/the_hoard_keyfile		auto
Isengard:~ #


Isengard:~ # grep hoard_1 /etc/fstab
/dev/mapper/cr_hoard_1			/data/hoard_1		xfs	user,lazytime,exec,nofail	1  2
Isengard:~ #

Isengard:~ # grep hoard_1 /etc/exports
/data/hoard_1			192.168.1.0/24(rw,no_root_squash,sync,subtree_check,fsid=10) 192.168.2.0/24(rw,no_root_squash,sync,subtree_check,fsid=10)
Isengard:~ #


If I umount and mount something else, I have to restart the nfs-server service. It is not automatic.




-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#66799

On 2025-04-02 13:40, vallor wrote:
> On Wed, 2 Apr 2025 13:14:44 +0200, "Carlos E.R." <robin_listas@es.invalid>
> wrote in <4qivblx7ff.ln2@Telcontar.valinor>:
> 

...

>> Reminds me of something. How does one know what version is actually
>> used?
> 
> use "mount | grep mountpoint", the version will be in there as "vers=",
> and also the type, e.g.:

Nope, empty output.

Telcontar:~ # mount | grep mountpoint
Telcontar:~ # mount | grep hoard
systemd-1 on /mnt/nfs/Isengard/hoard_1 type autofs (rw,relatime,fd=60,pgrp=1,timeout=300,minproto=5,maxproto=5,direct,pipe_ino=14617)
Isengard.valinor:/data/hoard_1 on /mnt/nfs/Isengard/hoard_1 type nfs4 (rw,nosuid,nodev,noexec,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.14,local_lock=none,addr=192.168.1.16,_netdev,user)


Ah, you mean replace mountpoint with the actual mountpoint :-)

> 
> $ mount | grep /nfs/ds
> 192.168.23.12:/volume1/ds on /nfs/ds type nfs4
> (rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,
> hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.23.254,
> local_lock=none,addr=192.168.23.12)
> 
> (I've wrapped the line for posting on Usenet.)

Bah, I disable line wrap. This is the XXI :-)


Ok, so the client shows the version. How about the server?

What I do, is use some option that is only valid on version 4, so I force version 4.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#66822

Carlos E.R. <robin_listas@es.invalid> wrote:
> 
> What I do, is use some option that is only valid on version 4,
> so I force version 4.

There's also the nfsvers=4 option.

-- 
__          __
#_ < |\| |< _#

[toc] | [prev] | [next] | [standalone]

#66831

On 4/3/25 2:40 AM, Computer Nerd Kev wrote:
> Carlos E.R. <robin_listas@es.invalid> wrote:
>>
>> What I do, is use some option that is only valid on version 4,
>> so I force version 4.
> 
> There's also the nfsvers=4 option.

   As noted somewhere else, I *do* see NFS4 in etab as
   a filled-in default.

   Also, PRE-filled subdirs under the share are sent to
   the clients properly, including file updates. The issue
   is with re-mounting USB drives OVER empty folders that
   were under the share folder at boot. Doesn't SEE the
   changes, only what was originally there.

   Mounts/re-mounts don't seem THAT unusual in Linux, so
   I'm kinda surprised NFS isn't dealing with it.

   Note external USB drives don't ALWAYS come up in the
   same order ... kinda depends on which order they fully
   init. Even a millisecond determines which will be
   sda, sdb, etc ... gotta name, or tagfile, the drives
   to make sure - Python can most easily find/parse that
   kind of info. But that's NEXT week ....

[toc] | [prev] | [next] | [standalone]

#66834

On 03/04/2025 11:19, c186282 wrote:
> On 4/3/25 2:40 AM, Computer Nerd Kev wrote:
>> Carlos E.R. <robin_listas@es.invalid> wrote:
>>>
>>> What I do, is use some option that is only valid on version 4,
>>> so I force version 4.
>>
>> There's also the nfsvers=4 option.
> 
>    As noted somewhere else, I *do* see NFS4 in etab as
>    a filled-in default.
> 
>    Also, PRE-filled subdirs under the share are sent to
>    the clients properly, including file updates. The issue
>    is with re-mounting USB drives OVER empty folders that
>    were under the share folder at boot. Doesn't SEE the
>    changes, only what was originally there.
> 
>    Mounts/re-mounts don't seem THAT unusual in Linux, so
>    I'm kinda surprised NFS isn't dealing with it.
> 
>    Note external USB drives don't ALWAYS come up in the
>    same order ... kinda depends on which order they fully
>    init. Even a millisecond determines which will be
>    sda, sdb, etc ... gotta name, or tagfile, the drives
>    to make sure - Python can most easily find/parse that
>    kind of info. But that's NEXT week ....
> 
> 
Oh dear. You really haven't grasped this have you?
1. Use fstab to PERMANTLY mount them at boot time before NFS even come up
2. use their partition UUIDs in fstab  to associate  each partition with 
a defined mount point.

e.g.

PARTUUID=0916c1e1-d006-4b19-9378-d687271d3612  /home               ext4 
   defau
lts,noatime  0       1
PARTUUID=aec7525a-1e13-4a52-a23f-d8a0d17f6da7  /home/Media 
ext4
  defaults,noatime  0       1
PARTUUID=778a9e44-03 /backup ext4    defaults,noatime  0       1
PARTUUID=778a9e44-06 /backup2 ext4    defaults,noatime  0       1
PARTUUID=778a9e44-05 /home/Media/Unedited ext4 defaults,noatime  0       1

These are all USB connected SSD partitions. They are all exported by NFS 
without problems.


-- 
Renewable energy: Expensive solutions that don't work to a problem that 
doesn't exist instituted by self legalising protection rackets that 
don't protect,  masquerading as public servants who don't serve the public.

[toc] | [prev] | [next] | [standalone]

#66836

On 4/3/25 7:03 AM, The Natural Philosopher wrote:
> On 03/04/2025 11:19, c186282 wrote:
>> On 4/3/25 2:40 AM, Computer Nerd Kev wrote:
>>> Carlos E.R. <robin_listas@es.invalid> wrote:
>>>>
>>>> What I do, is use some option that is only valid on version 4,
>>>> so I force version 4.
>>>
>>> There's also the nfsvers=4 option.
>>
>>    As noted somewhere else, I *do* see NFS4 in etab as
>>    a filled-in default.
>>
>>    Also, PRE-filled subdirs under the share are sent to
>>    the clients properly, including file updates. The issue
>>    is with re-mounting USB drives OVER empty folders that
>>    were under the share folder at boot. Doesn't SEE the
>>    changes, only what was originally there.
>>
>>    Mounts/re-mounts don't seem THAT unusual in Linux, so
>>    I'm kinda surprised NFS isn't dealing with it.
>>
>>    Note external USB drives don't ALWAYS come up in the
>>    same order ... kinda depends on which order they fully
>>    init. Even a millisecond determines which will be
>>    sda, sdb, etc ... gotta name, or tagfile, the drives
>>    to make sure - Python can most easily find/parse that
>>    kind of info. But that's NEXT week ....
>>
>>
> Oh dear. You really haven't grasped this have you?

   Clearly not ... enlighten me ......

> 1. Use fstab to PERMANTLY mount them at boot time before NFS even come up
> 2. use their partition UUIDs in fstab  to associate  each partition with 
> a defined mount point.

   Hmmm ...

   Haven't used fstab for external USBs in a long time,
   but it's worth a TRY here. I'll use the _netdev option
   to help cope with any delays.


> e.g.
> 
> PARTUUID=0916c1e1-d006-4b19-9378-d687271d3612  /home               ext4 
>    defau
> lts,noatime  0       1
> PARTUUID=aec7525a-1e13-4a52-a23f-d8a0d17f6da7  /home/Media ext4
>   defaults,noatime  0       1
> PARTUUID=778a9e44-03 /backup ext4    defaults,noatime  0       1
> PARTUUID=778a9e44-06 /backup2 ext4    defaults,noatime  0       1
> PARTUUID=778a9e44-05 /home/Media/Unedited ext4 defaults,noatime  0       1
> 
> These are all USB connected SSD partitions. They are all exported by NFS 
> without problems.

   Gimme a few hours and I'll report.

   Oh, I generally mount-by-label, not UUID, since the
   label TELLS you stuff.

[toc] | [prev] | [next] | [standalone]

#66838

On 03/04/2025 12:27, c186282 wrote:
> On 4/3/25 7:03 AM, The Natural Philosopher wrote:
>> On 03/04/2025 11:19, c186282 wrote:
>>> On 4/3/25 2:40 AM, Computer Nerd Kev wrote:
>>>> Carlos E.R. <robin_listas@es.invalid> wrote:
>>>>>
>>>>> What I do, is use some option that is only valid on version 4,
>>>>> so I force version 4.
>>>>
>>>> There's also the nfsvers=4 option.
>>>
>>>    As noted somewhere else, I *do* see NFS4 in etab as
>>>    a filled-in default.
>>>
>>>    Also, PRE-filled subdirs under the share are sent to
>>>    the clients properly, including file updates. The issue
>>>    is with re-mounting USB drives OVER empty folders that
>>>    were under the share folder at boot. Doesn't SEE the
>>>    changes, only what was originally there.
>>>
>>>    Mounts/re-mounts don't seem THAT unusual in Linux, so
>>>    I'm kinda surprised NFS isn't dealing with it.
>>>
>>>    Note external USB drives don't ALWAYS come up in the
>>>    same order ... kinda depends on which order they fully
>>>    init. Even a millisecond determines which will be
>>>    sda, sdb, etc ... gotta name, or tagfile, the drives
>>>    to make sure - Python can most easily find/parse that
>>>    kind of info. But that's NEXT week ....
>>>
>>>
>> Oh dear. You really haven't grasped this have you?
> 
>    Clearly not ... enlighten me ......
> 
>> 1. Use fstab to PERMANTLY mount them at boot time before NFS even come up
>> 2. use their partition UUIDs in fstab  to associate  each partition 
>> with a defined mount point.
> 
>    Hmmm ...
> 
>    Haven't used fstab for external USBs in a long time,
>    but it's worth a TRY here. I'll use the _netdev option
>    to help cope with any delays.
> 
> 

I think that is the wrong way round. IIRC _netdev delays mount until the 
network is up
You want to mount *before* bringing the network up...

_netdev is what I ought to use on my laptop ...


>> e.g.
>>
>> PARTUUID=0916c1e1-d006-4b19-9378-d687271d3612  /home               
>> ext4    defau
>> lts,noatime  0       1
>> PARTUUID=aec7525a-1e13-4a52-a23f-d8a0d17f6da7  /home/Media ext4
>>   defaults,noatime  0       1
>> PARTUUID=778a9e44-03 /backup ext4    defaults,noatime  0       1
>> PARTUUID=778a9e44-06 /backup2 ext4    defaults,noatime  0       1
>> PARTUUID=778a9e44-05 /home/Media/Unedited ext4 defaults,noatime  
>> 0       1
>>
>> These are all USB connected SSD partitions. They are all exported by 
>> NFS without problems.
> 
>    Gimme a few hours and I'll report.
> 
>    Oh, I generally mount-by-label, not UUID, since the
>    label TELLS you stuff.

Can do, but its easier to change the LABEL by accident, or duplicate it, 
than the UUID

-- 
"I am inclined to tell the truth and dislike people who lie consistently.
This makes me unfit for the company of people of a Left persuasion, and 
all women"

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.os.linux.misc

csiph-web