Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!border-4.nntp.ord.giganews.com!nntp.giganews.com!Xl.tags.giganews.com!local-4.nntp.ord.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 03 Apr 2025 15:27:14 +0000
From: c186282 <c186282@nnada.net>
Subject: Re: Here's One - NFS - Mounting Over Share = Nada
Newsgroups: comp.os.linux.misc
References: <UQ-dndQV6amaDnH6nZ2dnZfqnPednZ2d@giganews.com>
 <6ggvblxiu5.ln2@Telcontar.valinor> <vsj4l2$1jt3k$4@dont-email.me>
 <61jvblx7ff.ln2@Telcontar.valinor> <vsjqni$2bgo0$1@dont-email.me>
 <FLadnWvzcO68x3P6nZ2dnZfqnPidnZ2d@giganews.com>
 <68a2clxf62.ln2@Telcontar.valinor>
X-Mozilla-News-Host: news://news.giganews.com
Date: Thu, 3 Apr 2025 11:27:17 -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: <68a2clxf62.ln2@Telcontar.valinor>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <pImdnVzSPJVPNXP6nZ2dnZfqn_GdnZ2d@giganews.com>
Lines: 87
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-e4jmuwqLhORUWm969n97mo+CpJQTXH97WE2yk/ogaYRXuECJKB19KgDgQ2zNq2kZRBydGpXmiw7UrgR!hr8Jxm9WCdvm9cPPaSGxhPuLfYcGNgTIA1VKfslkgzNe8BhfaVdOdlHMe99O1b8VPc0RFal9vD4H
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/3/25 8:07 AM, Carlos E.R. wrote:
> On 2025-04-03 11:51, c186282 wrote:
>> On 4/2/25 1:04 PM, The Natural Philosopher wrote:
>>> On 02/04/2025 12:18, Carlos E.R. wrote:
>>>> On 2025-04-02 12:48, The Natural Philosopher wrote:
> 
> 
>>> I always start with ...
>>>
>>> *(ro,sync,no_root_squash,no_subtree_check)
>>>
>>> In /etc/exports for the least restricted export
>>
>>    Ok, tried your param list ... but still nada on
>>    the later-login mounts. Exportfs adds a bunch of
>>    other defaults to etab.
>>
>>    It's VERY annoying.
>>
>>    As best I can tell, NFS cuts in VERY early and there
>>    is no sane way to stop/delay it. As such it ONLY sees
>>    the original, empty, folder we are later gonna
>>    remount the USBs to.
> 
> It is working fine for me. You need "nohide" or version 4.
> 
>>
>>    Have a 4-drive external USB fixture. The drives USUALLY
>>    come up in order, but experience sez they won't ALWAYS
>>    do that. Depends on how quick the drives initialize,
>>    and there's one magnetic in the mix. sda/sdb/etc may
>>    not ALWAYS, reliably, be the same physical drives.
>>    A Python script can more easily probe/parse info that
>>    can individually identify, that's the next stage.
> 
> So, do not use sda/sdb. Use persistent naming.
> 
> 
>>    Anyway, the drives (sometimes) come up in /media/<user>
>>    and I have a mount statement that mounts them in my
>>    NFS share dir, under the appropriate sub-folder.
> 
> Define them in fstab.

   For you and rbowman ...

   Here's what my boxes look like now :

.. . . . .

server

/etc/exports :

/home/nas/shar 192.168.0.0/24(rw,sync,no_root_squash,no_subtree_check)

/etc/fstab :

LABEL=ustor1 /home/nas/shar/qshar1 ext4 defaults,_netdev 0 0
LABEL=ustor2 /home/nas/shar/qshar2 ext4 defaults,_netdev 0 0


client

/etc/fstab :

192.168.0.121:/home/nas/shar /mnt/shar nfs defaults, 
timeo=900,retrans=5,_netdev 0 0

.. . . . .

   Results - ON the server you can see both of the USB drives,
   so they ARE mounting where instructed. There is also a
   third subfolder under /shar that's directly written to by
   a script on the server box.

   On the CLIENT ... you can read/write to that third folder
   just fine. However the other two, the shares of the USB
   drives mounted on the server to, /home/nas/shar/qshar1 and
   /home/nas/shar/qshar2, are just BLANK.

   All permissions, server and client, are very generous
   for testing purposes - could restrict a bit later.

   MAY try sharing each folder under /shar individually
   rather that trying to share just /shar and hoping
   everything under it gets carried over - which it doesn't.