Deutsch   English   Français   Italiano  
<Hemcnbo7-rQhtXD6nZ2dnZfqn_SdnZ2d@giganews.com>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!border-4.nntp.ord.giganews.com!border-3.nntp.ord.giganews.com!nntp.giganews.com!Xl.tags.giganews.com!local-3.nntp.ord.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 02 Apr 2025 12:08:27 +0000
Subject: Re: Here's One - NFS - Mounting Over Share = Nada
Newsgroups: comp.os.linux.misc
References: <UQ-dndQV6amaDnH6nZ2dnZfqnPednZ2d@giganews.com>
 <m54j20Fhof8U3@mid.individual.net> <4qivblx7ff.ln2@Telcontar.valinor>
 <m54m11Fhof8U5@mid.individual.net>
From: c186282 <c186282@nnada.net>
Date: Wed, 2 Apr 2025 08:08:27 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <m54m11Fhof8U5@mid.individual.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <Hemcnbo7-rQhtXD6nZ2dnZfqn_SdnZ2d@giganews.com>
Lines: 92
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-ewbpTncF0uSTqAhOLrtDyZp8b57Dwq5yhJmJoHwNbtloLRRcYnD6P5Ut56Va9ib0fdUaYUsXPDJPNMU!te3fSQWk4YYVia2XdwVcgsGTztOzdagFNiFSiR6keVS9eJeCIvxDpBWr7cykoHs9huyhX2RvqrX6
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40

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 .......