On Thu, Aug 2, 2018 at 12:29 AM Ed Greshko wrote:
> On 08/01/18 23:22, Bob Goodwin wrote:
>> On 08/01/18 08:38, Ed Greshko wrote:
>>> On 08/01/18 20:17, Ed Greshko wrote:
On 08/01/18 19:37, Bob Goodwin wrote:
> On 08/01/18 07:31, Ed Greshko wrote:
>> ll /etc/exports
> Sorry, guess
On 08/01/18 12:44, Tom H wrote:
They are exported as read-only and, even if you
mount "/", you wouldn't be able to access the usual directories under
"/", like "/usr".
_
A limitation I don't want. As I said, I don't know where I got the
fsid-0 from but I will look back and se
On 08/01/18 17:41, Ed Greshko wrote:
I think TomH laid it out quite well.
Bottom line, best not configure the server for a feature you're not using or is
confusing. :-) :-)
.
Ok, that's obviously true. I dunno where it came from, must have been in
an example I collected ...
--
Bob Goodwin -
On 08/01/18 23:22, Bob Goodwin wrote:
> On 08/01/18 08:38, Ed Greshko wrote:
>> On 08/01/18 20:17, Ed Greshko wrote:
>>> On 08/01/18 19:37, Bob Goodwin wrote:
On 08/01/18 07:31, Ed Greshko wrote:
> ll /etc/exports
Sorry, guess I wasn't completely awake at the time ...
[bobg@
On Wed, Aug 1, 2018 at 3:02 PM Ed Greshko wrote:
> On 08/01/18 19:37, Bob Goodwin wrote:
>>
>> [bobg@ASRock-J3455M ~]$ cat /etc/exports
>> /home/exports
>> 192.168.1.0/24(rw,sync,insecure,no_root_squash,no_subtree_check,fsid=0)
>
> The problem with this line is "fsid=0".
>
> Remove that (not sure
On 08/01/18 08:38, Ed Greshko wrote:
On 08/01/18 20:17, Ed Greshko wrote:
On 08/01/18 19:37, Bob Goodwin wrote:
On 08/01/18 07:31, Ed Greshko wrote:
ll /etc/exports
Sorry, guess I wasn't completely awake at the time ...
[bobg@ASRock-J3455M ~]$ cat /etc/exports
/home/exports
192.168.1.0/24(r
On 08/01/18 08:17, Ed Greshko wrote:
The problem with this line is "fsid=0". Remove that (not sure what it is
for) and
it will work.
You are right.
With fsid=0, box 83 was rebooted and the server connection came up as
desired and a lag in getting data from the server also cleared.
Thanks
On 08/01/18 20:17, Ed Greshko wrote:
> On 08/01/18 19:37, Bob Goodwin wrote:
>> On 08/01/18 07:31, Ed Greshko wrote:
>>> ll /etc/exports
>> Sorry, guess I wasn't completely awake at the time ...
>>
>> [bobg@ASRock-J3455M ~]$ cat /etc/exports
>> /home/exports
>> 192.168.1.0/24(rw,sync,insecure,no_r
On 08/01/18 19:37, Bob Goodwin wrote:
> On 08/01/18 07:31, Ed Greshko wrote:
>> ll /etc/exports
> Sorry, guess I wasn't completely awake at the time ...
>
> [bobg@ASRock-J3455M ~]$ cat /etc/exports
> /home/exports
> 192.168.1.0/24(rw,sync,insecure,no_root_squash,no_subtree_check,fsid=0)
>
>
>
The
On 08/01/18 07:31, Ed Greshko wrote:
ll /etc/exports
Sorry, guess I wasn't completely awake at the time ...
[bobg@ASRock-J3455M ~]$ cat /etc/exports
/home/exports
192.168.1.0/24(rw,sync,insecure,no_root_squash,no_subtree_check,fsid=0)
--
Bob Goodwin - Zuni, Virginia, USA
http://www.qrz.com
On 08/01/18 18:50, Bob Goodwin wrote:
> On 07/31/18 17:46, Ed Greshko wrote:
>> Please post the
>>
>> /etc/exports file from the NFS Server
> [bobg@ASRock-J3455M ~]$ ll /etc/exports
> -rw-r--r--. 1 root root 87 Jul 20 11:13 /etc/exports
You only listed it. How about the contents?
>>
>> and
On 07/31/18 17:46, Ed Greshko wrote:
Please post the
/etc/exports file from the NFS Server
[bobg@ASRock-J3455M ~]$ ll /etc/exports
-rw-r--r--. 1 root root 87 Jul 20 11:13 /etc/exports
and the nfs related lines from the
/etc/fstab on a failing NFS Client
[root@Box10 bobg]# cat /etc/fs
Hi.
On Tue, 31 Jul 2018 10:42:42 -0700 Rick Stevens wrote:
> On 07/31/2018 10:23 AM, francis.montag...@inria.fr wrote:
>>> If you don't have the automount stuff, I think the most reliable thing
>>> is to give your client a fixed IP/netmask/gateway combination. ...
>> This may not be sufficient:
On 08/01/18 05:16, Bob Goodwin wrote:
> +
>
> On 07/31/18 16:59, Ed Greshko wrote:
>> I just saw the other message from Rick
>>
>> Is ASRock-J3455M the NFS client?
> +
>
> No, that is the NFS server.
>
> UPS just delivered a new Das keyboard i3 and I just had to check it out, I
> was off
> tra
+
On 07/31/18 16:59, Ed Greshko wrote:
I just saw the other message from Rick
Is ASRock-J3455M the NFS client?
+
No, that is the NFS server.
UPS just delivered a new Das keyboard i3 and I just had to check it out,
I was off track here for a while.
__
On 07/31/2018 01:59 PM, Ed Greshko wrote:
> On 08/01/18 01:37, Bob Goodwin wrote:
>> On 07/31/18 13:30, Bob Goodwin wrote:
>>> On 07/31/18 13:10, Ed Greshko wrote:
In a previous post, I wrote
systemctl show mnt-testb.automount
>>> +
>>> Sorry, here's a second go at doing mit righ
On 08/01/18 01:37, Bob Goodwin wrote:
> On 07/31/18 13:30, Bob Goodwin wrote:
>> On 07/31/18 13:10, Ed Greshko wrote:
>>> In a previous post, I wrote
>>>
>>> systemctl show mnt-testb.automount
>> +
>> Sorry, here's a second go at doing mit right:
> NO That's probably not what you want either be
On 07/31/2018 10:06 AM, Bob Goodwin wrote:
> On 07/31/18 12:35, Rick Stevens wrote:
>> If it's an automount with a "comment=systemd.automount" or
>> "x-systemd.automount" in the options of the fstab entry:
>>
>> server:/export /mnt/nfsmount nfs4
>> options,x-systemd.automount 0 0
>>
>>
On 07/31/2018 10:23 AM, francis.montag...@inria.fr wrote:
>
> Hi
>
> On Tue, 31 Jul 2018 09:35:27 -0700 Rick Stevens wrote:
>
>> If you don't have the automount stuff, I think the most reliable thing
>> is to give your client a fixed IP/netmask/gateway combination. ...
>
> This may not be suffi
On 07/31/18 13:30, Bob Goodwin wrote:
On 07/31/18 13:10, Ed Greshko wrote:
In a previous post, I wrote
systemctl show mnt-testb.automount
+
Sorry, here's a second go at doing mit right:
NO That's probably not what you want either because now the computer is
connected. I will shut it down
On 07/31/18 13:10, Ed Greshko wrote:
In a previous post, I wrote
systemctl show mnt-testb.automount
+
Sorry, here's a second go at doing mit right:
[bobg@ASRock-J3455M ~]$ systemctl show mnt-testb.automount
Where=/mnt/testb
DirectoryMode=0755
Result=success
TimeoutIdleUSec=0
Id=mnt-testb.
Hi
On Tue, 31 Jul 2018 09:35:27 -0700 Rick Stevens wrote:
> If you don't have the automount stuff, I think the most reliable thing
> is to give your client a fixed IP/netmask/gateway combination. ...
This may not be sufficient: I had a client with fixed IP configuration
that fails to mount an N
On 07/31/18 22:26, Bob Goodwin wrote:
> On 07/31/18 08:35, Ed Greshko wrote:
>> On 07/31/18 18:36, Bob Goodwin wrote:
>>> Wont it trigger the mount process as soon as I "startxfce4"?
>>
>> I think I mis-read this
>>
>> Are you saying you boot to a text login, login as yourself, and then start
On 07/31/18 12:35, Rick Stevens wrote:
If it's an automount with a "comment=systemd.automount" or
"x-systemd.automount" in the options of the fstab entry:
server:/export /mnt/nfsmount nfs4options,x-systemd.automount 0 0
you must_access_ the mountpoint for systemd to automount it
On 07/31/2018 03:36 AM, Bob Goodwin wrote:
> On 07/30/18 23:10, Ed Greshko wrote:
>> Well, to avoid triggering anything, I would boot the system and then use a
>> Virtual
>> Terminal (or ssh in) to login as root.
>>
>> Then I would do...
>>
>> systemctl status mnt-testb.automount
>>
>> and maybe
>
On 07/31/18 08:35, Ed Greshko wrote:
On 07/31/18 18:36, Bob Goodwin wrote:
Wont it trigger the mount process as soon as I "startxfce4"?
I think I mis-read this
Are you saying you boot to a text login, login as yourself, and then start your
desktop with "startxfce4"?
If that is the case,
On 07/31/18 18:36, Bob Goodwin wrote:
> Wont it trigger the mount process as soon as I "startxfce4"?
I think I mis-read this
Are you saying you boot to a text login, login as yourself, and then start your
desktop with "startxfce4"?
If that is the case, don't start it. Just login and issue
On 07/31/18 18:36, Bob Goodwin wrote:
> On 07/30/18 23:10, Ed Greshko wrote:
>> Well, to avoid triggering anything, I would boot the system and then use a
>> Virtual
>> Terminal (or ssh in) to login as root.
>>
>> Then I would do...
>>
>> systemctl status mnt-testb.automount
>>
>> and maybe
>>
>>
On 07/30/18 23:10, Ed Greshko wrote:
Well, to avoid triggering anything, I would boot the system and then use a
Virtual
Terminal (or ssh in) to login as root.
Then I would do...
systemctl status mnt-testb.automount
and maybe
systemctl show mnt-testb.automount
+
Wont it trigger the mount pro
On 07/31/18 05:56, Bob Goodwin wrote:
> On 07/30/18 17:46, Ed Greshko wrote:
>> If you do journalctl -b 0 | grep mount on the client, what does it show?
> +
>
>
>
> Jul 30 11:46:47 Box10 systemd[1]: mnt-testb.automount: Got automount request
> for
> /mnt/testb, triggered by 1670 (wish)
> Jul 30 11
On 07/31/18 08:45, Rick Stevens wrote:
> On 07/30/2018 04:45 PM, Ed Greshko wrote:
>> On 07/31/18 06:38, Ed Greshko wrote:
>>> I'd never seen log entries like the type Bob posted.
>>
>> Just as a test, I set up a VM as an NFS client with this in the fstab.
>>
>> ds6:/volume1/misty /home/egres
On 07/30/2018 04:45 PM, Ed Greshko wrote:
> On 07/31/18 06:38, Ed Greshko wrote:
>> I'd never seen log entries like the type Bob posted.
>
>
> Just as a test, I set up a VM as an NFS client with this in the fstab.
>
> ds6:/volume1/misty /home/egreshko/misty nfs4
> rw,soft,intr,fg,co
On 07/31/18 06:38, Ed Greshko wrote:
> I'd never seen log entries like the type Bob posted.
Just as a test, I set up a VM as an NFS client with this in the fstab.
ds6:/volume1/misty /home/egreshko/misty nfs4
rw,soft,intr,fg,comment=systemd.automount 0 0
I then ssh'd into the sy
On 07/30/18 18:09, Rick Stevens wrote:
I expect this is a race condition with NetworkManager-
wait-online.service. By default, it does a oneshot of:
nm-online -s -q --timeout=30
and nm-online COULD return a 1 if NM is running but hasn't brought up
the network yet due to a slow DHCP resp
On 07/31/18 06:09, Rick Stevens wrote:
> On 07/30/2018 02:56 PM, Bob Goodwin wrote:
>> On 07/30/18 17:46, Ed Greshko wrote:
>>> If you do
>>>
>>> journalctl -b 0 | grep mount
>>>
>>> on the client, what does it show?
>> +
>>
>> I guess this is not to long to send the entire result -
> I expect this
On 07/30/18 17:56, Bob Goodwin wrote:
On 07/30/18 17:46, Ed Greshko wrote:
If you do
journalctl -b 0 | grep mount
on the client, what does it show?
+
There are two servers shown there, box86, /mnt/testb is the one of
interest that has only recently quit connecting automatically. The smb
se
On 07/30/2018 02:56 PM, Bob Goodwin wrote:
> On 07/30/18 17:46, Ed Greshko wrote:
>> If you do
>>
>> journalctl -b 0 | grep mount
>>
>> on the client, what does it show?
> +
>
> I guess this is not to long to send the entire result -
>
> [bobg@Box10 ~]$ journalctl -b 0 | grep mount
> Jul 30 11:44
On 07/30/18 17:46, Ed Greshko wrote:
If you do
journalctl -b 0 | grep mount
on the client, what does it show?
+
I guess this is not to long to send the entire result -
[bobg@Box10 ~]$ journalctl -b 0 | grep mount
Jul 30 11:44:50 localhost.localdomain kernel: EXT4-fs (sdb1): mounted
filesyst
On 07/31/18 00:35, Bob Goodwin wrote:
> On 07/30/18 12:01, Bob Goodwin wrote:
>> On 07/30/18 10:57, Ed Greshko wrote:
>>> In your fstab you can try changing it to something like
>>>
>>> 192.168.1.86:/home/exports /mnt/testb nfs4
>>> rw,soft,intr,fg,comment=systemd.automount 0 0
>>>
>>>
On Mon, 30 Jul 2018 10:40:35 -0400
Bob Goodwin wrote:
> Fedora 27 and 28 that do not mount the nfs server
> at boot.
I always fix this using the big hammer work-around: mount them
from rc.local after a delay long enough to make sure the network
is really "up". This got more complicated when syst
On Mon, 30 Jul 2018 at 12:17, Bob Goodwin wrote:
> I have two computers, Fedora 27 and 28 that do not mount the nfs server
> at boot. It works from root afterward without any difficulty but that is
> a bit of an inconvenience. I put up with that problem with the Samba
> server for a long time but
On 07/30/18 12:01, Bob Goodwin wrote:
On 07/30/18 10:57, Ed Greshko wrote:
In your fstab you can try changing it to something like
192.168.1.86:/home/exports /mnt/testb nfs4
rw,soft,intr,fg,comment=systemd.automount 0 0
You may not see it mounted at boot time but as soon as you ac
On 07/30/18 10:57, Ed Greshko wrote:
In your fstab you can try changing it to something like
192.168.1.86:/home/exports /mnt/testb nfs4
rw,soft,intr,fg,comment=systemd.automount 0 0
You may not see it mounted at boot time but as soon as you access the directory
it
will become moun
On Mon, 2018-07-30 at 17:45 +0200, francis.montag...@inria.fr wrote:
> Hi.
>
> On Mon, 30 Jul 2018 10:40:35 -0400 Bob Goodwin wrote:
>
> > I have two computers, Fedora 27 and 28 that do not mount the nfs server
> > at boot. It works from root afterward without any difficulty ...
>
> This is per
On Mon, 2018-07-30 at 22:57 +0800, Ed Greshko wrote:
> On 07/30/18 22:40, Bob Goodwin wrote:
> > I have two computers, Fedora 27 and 28 that do not mount the nfs server at
> > boot. It
> > works from root afterward without any difficulty but that is a bit of an
> > inconvenience. I put up with tha
Hi.
On Mon, 30 Jul 2018 10:40:35 -0400 Bob Goodwin wrote:
> I have two computers, Fedora 27 and 28 that do not mount the nfs server
> at boot. It works from root afterward without any difficulty ...
This is perhaps (again) due to NetworkManager-wait-online.service
pretending too early that the
On 07/30/18 22:40, Bob Goodwin wrote:
> I have two computers, Fedora 27 and 28 that do not mount the nfs server at
> boot. It
> works from root afterward without any difficulty but that is a bit of an
> inconvenience. I put up with that problem with the Samba server for a long
> time but
> two is
I have two computers, Fedora 27 and 28 that do not mount the nfs server
at boot. It works from root afterward without any difficulty but that is
a bit of an inconvenience. I put up with that problem with the Samba
server for a long time but two is too much!
This problem was unknown until I bui
48 matches
Mail list logo
