Hello,
I have an external SSD
Disk /dev/sdd: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: Crucial X6 SSD
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk ident
install...
> so as not to be caught off guard in an emergency
Ok, but since the automount works when you access /home/myself/bertuccio
this is IMO not a problem.
That said, doing such a remote mount under a homedir is not
recommended:
- user processes may block if the NFS server do not respo
I log-in
The goal of automount, with autofs as well as with systemd.automount,
is to do the mount only when you access the mountpoint.
Why do you want that to be done when you log-in ?
No answer to this question :-(
Just to be sure that everything is working as in the previous install...
so as
On Sat, 31 May 2025 09:34:12 +0200 François Patte wrote:
> Le 30/05/2025 à 21:46, francis.montag...@inria.fr a écrit :
>> On Fri, 30 May 2025 17:52:06 +0200 François Patte wrote:
>>> I would like that the directory should be automounted when I log-in
>> The goal of automo
Le 30/05/2025 à 21:46, francis.montag...@inria.fr a écrit :
On Fri, 30 May 2025 17:52:06 +0200 François Patte wrote:
I would like that the directory should be automounted when I log-in
The goal of automount, with autofs as well as with systemd.automount,
is to do the mount only when you
Le 31/05/2025 à 04:35, Tim via users a écrit :
Barry:
The options include noauto
François Patte:
Thank you for this remark! I changed to auto and and it doesn't go up either
I wonder if your network is up and ready for use by this stage.
Do you mean network 192.168 ? Yes it is.
F.P
Barry:
>> The options include noauto
François Patte:
> Thank you for this remark! I changed to auto and and it doesn't go up
> either
I wonder if your network is up and ready for use by this stage.
--
uname -rsvp
Linux 3.10.0-1160.119.1.el7.x86_64 #1 SMP Tue Jun 4 14:43:51 UTC 2024 x86_6
On Fri, 30 May 2025 17:52:06 +0200 François Patte wrote:
> I would like that the directory should be automounted when I log-in
The goal of automount, with autofs as well as with systemd.automount,
is to do the mount only when you access the mountpoint.
Why do you want that to be done when
; Why it is not automaticlly mounted when I loggin?
> >>>
> >> The options include noauto
> >>
> > I was about to say that, but 'noauto' (according to the fstab man page)
> > means "don't include in 'mount -a, e.g. at boot". I suspect the
o the fstab man page)
means "don't include in 'mount -a, e.g. at boot". I suspect the OP
wants to automount the directory when it's accessed, which is what the
old automount system used to do.
I would like that the directory should be automounted when I log-
page)
means "don't include in 'mount -a, e.g. at boot". I suspect the OP
wants to automount the directory when it's accessed, which is what the
old automount system used to do.
poc
--
___
users mailing list -- users@li
> On 30 May 2025, at 16:37, François Patte wrote:
>
> Thank you for this remark! I changed to auto and and it doesn't go up
> either
>
>
Did you reboot to test?
I have a less complex line in my /etc/fstab to mount a NFS share.
Maybe one of the other options is the problem?
ser
Le 30/05/2025 à 17:20, Barry a écrit :
On 30 May 2025, at 14:05, François Patte wrote:
Why it is not automaticlly mounted when I loggin?
The options include noauto
Thank you for this remark! I changed to auto and and it doesn't go up
either
F.P.
--
_
> On 30 May 2025, at 14:05, François Patte wrote:
>
> Why it is not automaticlly mounted when I loggin?
The options include noauto
Barry
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.
Bonjour,
I added in /etc/fstab this line:
192.168.1.16:/data /home/myself/bertuccio nfs
noauto,rw,user,nofail,soft,x-systemd.automount,x-systemd.mount-timeout=30
0 0
I expected that the folder /data from 192.168.1.16 would be mounted
automatically but it is not the case... it is mounted onl
ve only in /etc/nsswitch.conf: automount: ldap
Yeah, I had only this in the nsswitch.conf.
I looked at both init.d scripts and noticed that in version 4.1.4 the
maptype cannot be set to LDAP. There is this if-else statement that
determines the map type and it always defaults to "yp".
pe you have only in /etc/nsswitch.conf: automount: ldap
> I looked at both init.d scripts and noticed that in version 4.1.4 the
> maptype cannot be set to LDAP. There is this if-else statement that
> determines the map type and it always defaults to "yp". There does not
> ev
On 19.08.2023 17:49, francis.montag...@inria.fr wrote:
I looked at the 4.1.4-33 version of /etc/init.d/autofs.
It uses autofs-ldap-auto-master to get the master map, and then calls an
automount process with each map found.
This list of automount commands is shown by "/etc/init.d/autofs s
Hi.
On Wed, 16 Aug 2023 20:41:06 +0200 Souji Thenria via users wrote:
> I have a rather odd question: Can anyone help me get automount version
> 4.1.4-33 to work with LDAP on a Fedora Core Release 5?
> So far, automount has worked for every machine I have migrated. However,
> whe
On 08/16/2023 01:38 PM, Souji Thenria via users wrote:
There is no encryption and no authentication needed for accessing the
automount maps. This was already disabled to support the clients which
use automount version 4.1.3.
OK; it was only a guess anyway
s
of FC 5 (one version older than the first one I used) it's not going to
work, and I doubt there's a way to correct that.
Hello Joe,
Thanks for your response.
There is no encryption and no authentication needed for accessing the
automount maps. This was already disabled to suppo
On 08/16/2023 12:41 PM, Souji Thenria via users wrote:
Does anyone have any idea what might be missing?
I'm not familiar with LDAP, but it occurs to me that there might be some
sort of encryption involved. If so, and it wasn't used back in the days
of FC 5 (one version older than the first o
Dear members of this mailing list,
I have a rather odd question: Can anyone help me get automount version
4.1.4-33 to work with LDAP on a Fedora Core Release 5?
(Fedora Core Release 5 is by now somewhat 16 years old, but for internal
reasons it is still needed and cannot be replaced easily)
The
>
> > Any ideas?
> >
> not for btrfs-automount-case.
> but you {s,c]ould check with your script if the drive is mounted
> *before* backup starts.
> And I would check if the mount point is still clean (in case the backup
> blindy backuped to the mount point wit
...
> The drive is normally only used at 3am to run a backup
> script, ...
> When I mount the drive manually, the timeout always succeeds (though
> again after 300 seconds rather than 120).
>
> Any ideas?
>
not for btrfs-automount-case.
but you {s,c]ould check with you
I use automount with systemd service units (not /etc/fstab) to mount an
external BTRFS filesystem (2 drives configured as RAID-1). There is a
timeout of 120 seconds of inactivity after which it should unmount.
This works *nearly* all the time, but sometimes it doesn't and I can't
figu
check the documentnot uncommon. :-)
>
> "Note that this option can only be used in /etc/fstab, and will be
> ignored when part of the Options= setting in a unit file."
>
> I have "TimeoutIdleSec=60" in the automount unit.
Yes, that's what I did too. The
The duration of this tread has me laughing at the systemd
"Biggest Myths" web page again:
http://0pointer.de/blog/projects/the-biggest-myths.html
Especially the claims that it is easily scriptable :-).
___
users mailing list -- users@lists.fedoraproject
of the Options= setting in a unit file."
I have "TimeoutIdleSec=60" in the automount unit.
--
Remind me to ignore comments which aren't germane to the thread.
___
users mailing list -- users@lists.fedoraproject.org
To un
On Wed, 2021-03-24 at 06:02 +0800, Ed Greshko wrote:
> On 23/03/2021 18:57, Patrick O'Callaghan wrote:
> > Sure, I'd like to see it. I've been testing various mods to the
> > whole
> > thing because I couldn't get it to work reliably, i.e. the loop
> > waiting
> > for the unmount would work when ru
On Tue, 2021-03-23 at 22:40 +, Patrick O'Callaghan wrote:
> On Wed, 2021-03-24 at 06:02 +0800, Ed Greshko wrote:
> > On 23/03/2021 18:57, Patrick O'Callaghan wrote:
> > > Sure, I'd like to see it. I've been testing various mods to the
> > > whole
> > > thing because I couldn't get it to work re
On Wed, 2021-03-24 at 06:02 +0800, Ed Greshko wrote:
> On 23/03/2021 18:57, Patrick O'Callaghan wrote:
> > Sure, I'd like to see it. I've been testing various mods to the
> > whole
> > thing because I couldn't get it to work reliably, i.e. the loop
> > waiting
> > for the unmount would work when ru
On 23/03/2021 18:57, Patrick O'Callaghan wrote:
Sure, I'd like to see it. I've been testing various mods to the whole
thing because I couldn't get it to work reliably, i.e. the loop waiting
for the unmount would work when run directly from the shell, but not
when run from a systemd service. I thi
On Tue, 2021-03-23 at 14:08 +0800, Ed Greshko wrote:
> On 18/03/2021 23:01, Patrick O'Callaghan wrote:
> > Sure.
> >
> > I'll report back once I've tested for a few days.
>
> Today was a slow day. So I implemented the "dock-down" with a timer
> instead of
> a while loop. Let me know if you're
On 18/03/2021 23:01, Patrick O'Callaghan wrote:
Sure.
I'll report back once I've tested for a few days.
Today was a slow day. So I implemented the "dock-down" with a timer instead of
a while loop. Let me know if you're interested in it.
--
Remind me to ignore comments which aren't germane
On Thu, 2021-03-18 at 06:50 +0800, Ed Greshko wrote:
> On 17/03/2021 23:10, Ed Greshko wrote:
> > On 17/03/2021 22:22, Patrick O'Callaghan wrote:
> > > On Mon, 2021-03-15 at 10:40 +0800, Ed Greshko wrote:
> > > > On 15/03/2021 07:37, Patrick O'Callaghan wrote:
> > > > > The only remaining problem (
On 17/03/2021 23:10, Ed Greshko wrote:
On 17/03/2021 22:22, Patrick O'Callaghan wrote:
On Mon, 2021-03-15 at 10:40 +0800, Ed Greshko wrote:
On 15/03/2021 07:37, Patrick O'Callaghan wrote:
The only remaining problem (touch wood) is to get the power-down
script
to run after a timeout. I'll consi
On 17/03/2021 22:22, Patrick O'Callaghan wrote:
On Mon, 2021-03-15 at 10:40 +0800, Ed Greshko wrote:
On 15/03/2021 07:37, Patrick O'Callaghan wrote:
The only remaining problem (touch wood) is to get the power-down
script
to run after a timeout. I'll consider writing a special script to
monitor
On Mon, 2021-03-15 at 10:40 +0800, Ed Greshko wrote:
> On 15/03/2021 07:37, Patrick O'Callaghan wrote:
> > The only remaining problem (touch wood) is to get the power-down
> > script
> > to run after a timeout. I'll consider writing a special script to
> > monitor the mount status independently of
On 15/03/2021 07:37, Patrick O'Callaghan wrote:
The only remaining problem (touch wood) is to get the power-down script
to run after a timeout. I'll consider writing a special script to
monitor the mount status independently of systemd.
You can consider using the timer/service pair of systemd.
; systemctl status dock.service
> > # systemctl status raid.mount
> > ● raid.mount - External /raid mount
> > Loaded: loaded (/etc/systemd/system/raid.mount; disabled; vendor
> > preset: disabled)
> > Active: inactive (dead)
> > Where: /raid
> >
.automount
● raid.automount - Automount /raid
Loaded: loaded (/etc/systemd/system/raid.automount; disabled;
vendor preset: disabled)
Active: inactive (dead)
Triggers: ● raid.mount
Where: /raid
# systemctl status dock.service
● dock.service - Power the dock up
Loaded: lo
ere: /raid
What: /dev/md0p1
# systemctl status raid.automount
● raid.automount - Automount /raid
Loaded: loaded (/etc/systemd/system/raid.automount; disabled;
vendor preset: disabled)
Active: inactive (dead)
Triggers: ● raid.mount
Where: /raid
# systemctl status dock.service
● dock.
On 15/03/2021 00:31, Patrick O'Callaghan wrote:
I rebooted and got:
# findmnt /raid
# ls /raid
# findmnt /raid
#
IOW nothing happens.
systemctl status raid.mount
systemctl status raid.automount
systemctl status dock.service
and finally
mount /raid
--
People who believe they don't make mist
utomounting to work:
> > Also, the .service is not being invoked by the .mount (I shouldn't
> > have
> > to start it manually), presumably because the .automount isn't
> > running.
>
> I modified my aux.mount unit to be
>
> [Unit]
> Description=nfs
On Sun, 2021-03-14 at 18:11 +1030, Tim via users wrote:
> On Fri, 2021-03-12 at 11:18 +, Patrick O'Callaghan wrote:
> > I do. The @reboot suggestion is only a partial solution. Given that
> > the drive is automatically powered up on reboot (there seems to be no
> > way to prevent this as it's t
On Fri, 2021-03-12 at 11:18 +, Patrick O'Callaghan wrote:
> I do. The @reboot suggestion is only a partial solution. Given that
> the drive is automatically powered up on reboot (there seems to be no
> way to prevent this as it's triggered by the system scanning the USB
> bus) I need to be able
need separate dock-up and dock-down services?
I suppose. But, I can't say that there is a way to start a service went the
auto-unmount occurs.
Also, the .service is not being invoked by the .mount (I shouldn't have
to start it manually), presumably because the .automount isn't r
deed. Does that mean I need separate dock-up and dock-down services?
Also, the .service is not being invoked by the .mount (I shouldn't have
to start it manually), presumably because the .automount isn't running.
BTW, is there a recommended way to re-run this kind of test cleanly,
without
On 14/03/2021 03:02, Patrick O'Callaghan wrote:
I assume there must be a basic error here, but I'm at a loss.
I like to crawl before I walk and walk before I run.
Even then, I see a pitfall in your plan. So, I created a test
/etc/systemd/system/dock.service.
[root@f33k system]# cat dock.ser
fore it can be mounted (kAFS, see kafs-utils
> package). It isn’t as complicated as the usb power on/off, but not outside
> of the realm of possibility.
I modified the .mount and .service files from kasf-client, and added a
.automount file. I also commented out the appropriate line in
On Sat, 2021-03-13 at 08:49 -0500, Jonathan Billings wrote:
> On Mar 12, 2021, at 19:05, Ed Greshko wrote:
> >
> > I don't think systemd was meant to solve these sorts of issues
>
> Honestly, systemd is more equipped to handle this kind of issue than any init
> system before it. Being able to
On Mar 12, 2021, at 19:05, Ed Greshko wrote:
>
> I don't think systemd was meant to solve these sorts of issues
Honestly, systemd is more equipped to handle this kind of issue than any init
system before it. Being able to attach dependencies in a .mount unit to a
.service unit is something th
.. My understanding is that the HW you have doesn't power-down
> or power-up (wake-up) in response to an unmount or mount operation.
Does any hardware do this when connected via USB?
> So, in the case of automount/autounmount you need "something" to
>
> issue power-
red.
That statement confuses me. Isn't that what happens with automount
and the TimeoutIdleSec=
parameter?
Of course it's possible that sending some command to the dock would
power down the drives, but the thing has no useful documentation. It
just comes with (of course) a Windows
riggered.
>
> That statement confuses me. Isn't that what happens with automount
> and the TimeoutIdleSec=
> parameter?
The automount correctly unmounts the drive. That isn't the problem. The
problem is in getting the drive to power down after it has been
unmounted. Thi
unning when the share goes from unmounted to mounted?
Just a timer. Once it's powered up and mounted, it should stay that way
until an idle timeout is triggered.
That statement confuses me. Isn't that what happens with automount and the
TimeoutIdleSec=
parameter?
Again, I somehow got t
On Fri, 2021-03-12 at 19:36 +0800, Ed Greshko wrote:
> On 12/03/2021 19:18, Patrick O'Callaghan wrote:
> > On Fri, 2021-03-12 at 17:01 +0800, Ed Greshko wrote:
> > > On 11/03/2021 21:14, Patrick O'Callaghan wrote:
> > > > Someone on the SystemD list suggested using an @reboot line in crontab
> > >
On 12/03/2021 19:18, Patrick O'Callaghan wrote:
On Fri, 2021-03-12 at 17:01 +0800, Ed Greshko wrote:
On 11/03/2021 21:14, Patrick O'Callaghan wrote:
Someone on the SystemD list suggested using an @reboot line in crontab
for this, as a special case.
While I didn't think of that option, I someho
On Fri, 2021-03-12 at 17:01 +0800, Ed Greshko wrote:
> On 11/03/2021 21:14, Patrick O'Callaghan wrote:
> > Someone on the SystemD list suggested using an @reboot line in crontab
> > for this, as a special case.
>
> While I didn't think of that option, I somehow got the impression that you
> neede
On 11/03/2021 21:14, Patrick O'Callaghan wrote:
Someone on the SystemD list suggested using an @reboot line in crontab
for this, as a special case.
While I didn't think of that option, I somehow got the impression that you
needed/wanted to run a script of
some sort each time the share was moun
On Thu, Mar 11, 2021 at 01:13:08PM +, Patrick O'Callaghan wrote:
>
> Yes, I had noticed that. What isn't clear to me is how this would work
> on system reboot. I need to be able to power down the drive not just
> after it's unmounted, but when the system is rebooted and the drive
> hasn't been
gt; > Diving into systemd documentation it seems that the sections included in
> > > the mount and automount unit files
> > > don't define those lines. :-(
> >
> > There isn’t anything about exec lines in a .mount unit, which is why I said
> > to have
On Thu, 2021-03-11 at 07:47 -0500, Jonathan Billings wrote:
> On Mar 10, 2021, at 20:18, Ed Greshko wrote:
> >
> > The answer may be "none of the above".
> >
> > Diving into systemd documentation it seems that the sections included in
> > the moun
On Mar 10, 2021, at 20:18, Ed Greshko wrote:
>
> The answer may be "none of the above".
>
> Diving into systemd documentation it seems that the sections included in the
> mount and automount unit files
> don't define those lines. :-(
There isn’t anything
the above".
> >
> > Diving into systemd documentation it seems that the sections included in
> > the mount and automount unit files
> > don't define those lines. :-(
> >
>
> Oh, one route you can consider is to post the query to
>
> systemd-de...@li
On 11/03/2021 09:17, Ed Greshko wrote:
On 11/03/2021 01:40, Patrick O'Callaghan wrote:
I now have to work out where to put the ExecStart/Stop lines.
The answer may be "none of the above".
Diving into systemd documentation it seems that the sections included in the
mount and
On 11/03/2021 01:40, Patrick O'Callaghan wrote:
I now have to work out where to put the ExecStart/Stop lines.
The answer may be "none of the above".
Diving into systemd documentation it seems that the sections included in the
mount and automount unit files
don'
On Wed, 2021-03-10 at 23:04 +0800, Ed Greshko wrote:
> On 10/03/2021 22:35, Ed Greshko wrote:
> > Also, due to the late hour, I seem to recall seeing something about working
> > with automounts and external devices
> > and conflicts arising due to the interference of udev. But I may be mixing
>
On Wed, 2021-03-10 at 22:35 +0800, Ed Greshko wrote:
> On 10/03/2021 20:57, Patrick O'Callaghan wrote:
> >
> > [Sorry for the long delay, but other stuff intervened.]
> >
> > I've come back to this now and started experimenting incrementally. As
> > a f
On 10/03/2021 22:35, Ed Greshko wrote:
Also, due to the late hour, I seem to recall seeing something about working
with automounts and external devices
and conflicts arising due to the interference of udev. But I may be mixing
things. So, I'd first see if making the
above changes has any effe
On 10/03/2021 20:57, Patrick O'Callaghan wrote:
[Sorry for the long delay, but other stuff intervened.]
I've come back to this now and started experimenting incrementally. As
a first step, I just want to automount/unmount, ignoring the power-
on/off part for now, i.e. the device
; >
>
> Well, using systemd units that should be possible. I use systemd to
> automount nfs.
> For one in particular I have
>
> [egreshko@meimei system]$ cat aux.automount
> [Unit]
> Description=Automount Aux
>
> [Automount]
> Where=/aux
> TimeoutIdleSec
On Sun, 2021-02-28 at 18:03 -0700, Chris Murphy wrote:
> On Sun, Feb 28, 2021 at 10:13 AM Patrick O'Callaghan
> wrote:
> >
> > Is there a way to invoke scripts before auto-mounting and after auto-
> > unmounting? I want to be able to power an external drive up and down as
> > needed.
>
> If you
On Sun, Feb 28, 2021 at 10:13 AM Patrick O'Callaghan
wrote:
>
> Is there a way to invoke scripts before auto-mounting and after auto-
> unmounting? I want to be able to power an external drive up and down as
> needed.
If you don't need much sophistication, you can add to fstab with options:
noaut
On Sun, 2021-02-28 at 16:18 -0500, Jonathan Billings wrote:
> On Feb 28, 2021, at 12:13, Patrick O'Callaghan wrote:
> >
> > Is there a way to invoke scripts before auto-mounting and after auto-
> > unmounting? I want to be able to power an external drive up and down as
> > needed.
>
> Your .mou
On Mon, 2021-03-01 at 03:27 +0800, Ed Greshko wrote:
> I would think using "ExecStartPre=" and "ExecStartPost=" would get you want
> you desire.
OK, that looks promising. I have some reading to do (though I've always
found the systemd docs fairly impenetrable).
poc
__
On Feb 28, 2021, at 12:13, Patrick O'Callaghan wrote:
>
> Is there a way to invoke scripts before auto-mounting and after auto-
> unmounting? I want to be able to power an external drive up and down as
> needed.
Your .mount unit would need a Before= and After= Section. Refer to a systemd
.ser
On 01/03/2021 03:27, Ed Greshko wrote:
I would think using "ExecStartPre=" and "ExecStartPost=" would get you want you desire.
Oh, there is also "ExecStop=" and "ExecStart=".
So, more "research" would be needed. But not at 03:40. :-)
--
People who believe they don't make mistakes have alread
On 01/03/2021 01:12, Patrick O'Callaghan wrote:
Is there a way to invoke scripts before auto-mounting and after auto-
unmounting? I want to be able to power an external drive up and down as
needed.
Well, using systemd units that should be possible. I use systemd to automount
nfs.
For o
Is there a way to invoke scripts before auto-mounting and after auto-
unmounting? I want to be able to power an external drive up and down as
needed.
poc
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@
t services.
An automount that requires networking is best left out. I prefer to never
touch fstab on my systems, leaving the installer to create them. Mostly
because automation is paramount and fstab is a monolithic config file, and
modifying it with tools like puppet or Ansible can leave it
On 1/1/21 12:52 PM, Jonathan Billings wrote:
> Is there a reason why people are using fstab entries with long and
> hard to read arguments instead of using .automount and .mount systemd
> units?
Is there a reason why Anaconda create /etc/fstab entries on a fresh
installation of Fedora
On Fri, Jan 01, 2021 at 11:52:52AM -0500, Jonathan Billings wrote:
> Is there a reason why people are using fstab entries with long and hard to
> read arguments instead of using .automount and .mount systemd units?
> Systemd is just dynamically generating the units from the fstab entrie
isted and this was just an omission in the
> documentation. Or,
> if they were not yet implemented.
Is there a reason why people are using fstab entries with long and hard to read
arguments instead of using .automount and .mount systemd units? Systemd is
just dynamically generating the unit
Hi.
On Fri, 01 Jan 2021 11:48:21 +0800 Ed Greshko wrote:
> On 01/01/2021 10:44, Tim via users wrote:
>> francis.montag...@inria.fr:
>>>> Using autofs instead of systemd-automount would have the advantage
>>>> to unmount automatically after some delay.
>>
On 01/01/2021 10:44, Tim via users wrote:
francis.montag...@inria.fr:
Using autofs instead of systemd-automount would have the advantage
to unmount automatically after some delay.
Ed Greshko:
Not true.
When did that change? That's how it's behaved for me, for many years.
I wen
francis.montag...@inria.fr:
>> Using autofs instead of systemd-automount would have the advantage
>> to unmount automatically after some delay.
Ed Greshko:
> Not true.
When did that change? That's how it's behaved for me, for many years.
I went to using autofs to au
On 31Dec2020 11:08, Greg Woods wrote:
>On Wed, Dec 30, 2020 at 11:04 PM Chris Murphy
>wrote:
>> On Wed, Dec 30, 2020 at 10:12 AM Greg Woods
>> wrote:
>> > pub.automount: Got automount request for /pub, triggered by 242640
>> (PT3122): 1 Time(s)
>>
On Dec 31, 2020, at 13:10, Greg Woods wrote:
> Yes. The format is "Got automount request for /pub, triggered by #PID#
> (#command#): 1 Time(s)
>
> I suppose I should provide more info. /pub is a place where I store a bunch
> of stuff. In particular there are our photo a
On 01/01/2021 04:49, francis.montag...@inria.fr wrote:
I admit to not have re-read the man of systemd.automount since F17
LOL!
---
The key to getting good answers is to ask good questions.
___
users mailing list -- users@lists.fedoraproject.org
To un
Hi
On Fri, 01 Jan 2021 03:26:07 +0800 Ed Greshko wrote:
> On 01/01/2021 00:24, francis.montag...@inria.fr wrote:
>> Using autofs instead of systemd-automount would have the advantage to
>> unmount automatically after some delay.
> Not true.
> Just use something like x-sy
7;d guess that it's related to polling for repo differences.
> Again, process 253560 is long gone, but at least I know that this automount
> was triggered by a dnf command. When the command is "PT3122", then I have no
> clue what triggered this automount.
No idea.
I
On 01/01/2021 00:24, francis.montag...@inria.fr wrote:
Using autofs instead of systemd-automount would have the advantage to
unmount automatically after some delay.
Not true.
Just use something like x-systemd.idle-timeout=60,x-systemd.mount-timeout=30 in
the fstab entry.
---
The key to
On Wed, Dec 30, 2020 at 11:04 PM Chris Murphy
wrote:
> On Wed, Dec 30, 2020 at 10:12 AM Greg Woods wrote:
>
> > pub.automount: Got automount request for /pub, triggered by 242640
> (PT3122): 1 Time(s)
> >
> > I want to determine why this is happening, because the dr
now)
follow symlinks.
gvfsd (the gnome virtual filesystem) used to do its mount under ~/.gfvs,
but do it now under /run/user/$UID/gvfs
Using autofs instead of systemd-automount would have the advantage to
unmount automatically after some delay.
You can
On Wed, Dec 30, 2020 at 10:12 AM Greg Woods wrote:
>
> My logwatch each day has dozens of messages like this:
>
> pub.automount: Got automount request for /pub, triggered by 242640 (PT3122):
> 1 Time(s)
>
> I want to determine why this is happening, because the drive con
My logwatch each day has dozens of messages like this:
pub.automount: Got automount request for /pub, triggered by 242640
(PT3122): 1 Time(s)
I want to determine why this is happening, because the drive
containing /pub (on a different machine mounted via NFS) is spun down when
idle, and these
On 30/12/2020 22:09, François Patte wrote:
Bonjour,
I configured an automount of directories located on a server on my local
network: in the fstab of a computer on the network I put the line:
192.168.1.16:/data /home/patte/data nfs
noauto,rw,user,nofail,x-systemd.automount,x-systemd.mount
Bonjour,
I configured an automount of directories located on a server on my local
network: in the fstab of a computer on the network I put the line:
192.168.1.16:/data /home/patte/data nfs
noauto,rw,user,nofail,x-systemd.automount,x-systemd.mount-timeout=30 0 0
It works. If the server is
1 - 100 of 176 matches
Mail list logo
