Re: Fedora Server 29 do not store last history when reboot without logout
Il giorno lun, 19/11/2018 alle 13.05 -0500, Garry Williams ha scritto: > Naw. No bug. systemd sends SIGTERM to each running process > atshutdown time. If the process fails to exit, systemd then sends > aSIGKILL. > The shell ignores SIGTERM. Yes, ignore it I have try to kill my shell pid and nothing happen. I have try to kill $PPID (my parent process id "sshd: root@pts/0") and logout + history saved is happen then, systemd send SIGTERM to all process, and when sshd get it, close the shell ... how to close it if SIGTERM is ignored from it? when the system goes down, How does bash know that it must to save the history? I suspect the shell is terminated with a -9 I have try to recreate the issue with some reboot and poweroff the server for a while and the history is always saved. This morning I have work on server a while then reboot it and the last history it's go away, nothing has been saved. How to I get rid on this (my?) issue ? Many thanks -- Dario Lesca (inviato dal mio Linux Fedora 28 Workstation) ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
df -H shows irritating values
Hello, I have a 64GB USB-Stick inserted to my Fritz!Box which is available as a SMB mount point. When I mount it "df -H" shows Filesystem Size Used Avail . Mounted on .. //fritz.box/nil123G38G86G 31% /nas All values are doubled (except the Use% of course). What's going on there? Kind regards, Frank ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Fedora Server 29 do not store last history when reboot without logout
On 11/20/18 4:50 AM, Dario Lesca wrote: How to I get rid on this (my?) issue ? Use "exec reboot" instead of "reboot". Close all of your other active shells before you do. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: df -H shows irritating values
On 11/20/18 5:45 AM, Frank Elsner wrote: I have a 64GB USB-Stick inserted to my Fritz!Box which is available as a SMB mount point. When I mount it "df -H" shows Filesystem Size Used Avail . Mounted on .. //fritz.box/nil123G38G86G 31% /nas What does "df -h" show? ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Fedora Server 29 do not store last history when reboot without logout
Il giorno mar, 20/11/2018 alle 08.02 -0800, Gordon Messmer ha scritto: > Use "exec reboot" instead of "reboot". Close all of your other > active shells before you do. Ok, thank, this can be a possible solution but it will be difficult to avoid the habit of writing only "reboot" ... to lose last history is very annoyng Why this kind of problem occur only some time? Has anyone had this kind of problem? I must fill a bug? IMHO: Seem this problem occur only on Fedora Server On Centos 7 this kind of problem has never happened (to me). Thanks -- Dario Lesca (inviato dal mio Linux Fedora 28 Workstation) ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Fedora Server 29 do not store last history when reboot without logout
On 11/20/2018 10:03 AM, Dario Lesca wrote: Ok, thank, this can be a possible solution but it will be difficult to avoid the habit of writing only "reboot" ... to lose last history is very annoyng Try adding this line to ~/.bashrc: alias reboot='exec reboot' ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Fedora Server 29 do not store last history when reboot without logout
Il giorno mar, 20/11/2018 alle 10.11 -0700, Joe Zeff ha scritto: > Try adding this line to ~/.bashrc: > alias reboot='exec reboot' Yes, thanks, also this can be a workaround. But i can think also for other people, if in case this annoying problem also affects other people. Then, if this is the only solution, it's bette I fill a bug in order to put this new alias into /etc/profile* or something similar Or there is another better solution? it could probably be useful to invest on why it happens. If you let me know what I can verify I do Thanks -- Dario Lesca (inviato dal mio Linux Fedora 28 Workstation) ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: VPN Interface not Remaining Active With Firewall?
On 19/11/18 10:13 am, Ed Greshko wrote: On 11/19/18 5:08 AM, Stephen Morris wrote: From recollection, which may not be completely accurate, the Asrock motherboard that I have now is the first motherboard I've had where the bios has not offered a setting to set the system clock to GMT/Local, and I have always set the system clock to local because Windows, which I tri-boot with, used to have issues with the system clock being GMT. Having said this, on this motherboard there isn't any option to change it, the front screen is showing local time and that time is correct for daylight savings time, even though the machine wasn't switched on when daylight savings time kicked in. I also seem to remember that there used to be an option in KDE->System Settings to configure whether or not the system clock was running local or GMT time, which I can't find now. The only setting I can find is to set the timezone and to set the date and time automatically. From memory there used to also be an option in KDE->System Setttings to have the clock maintained by a Network Time Clock where you could also specify the URL to connect to, which I used to have set to an Oceania location, but I can't find that anymore either. Think about it for a moment. Does it make any sense for a motherboard to have knowledge of time zones? The same motherboard is used all over the world and unless you update the BIOS they would remain static in their knowledge to time zones. I'm not saying the motherboard bios has knowledge of timezones, what I am saying is that other motherboards I've had have provided the facility when setting the time in the bios to specify whether the time being input is local time or GMT time. I've pointed out where time zone information is kept. Those files are provided by the tzdata package. Here is the start of the "changelog" for that package. * Mon Nov 12 2018 Patsy Griffin Franklin - 2018g-1 - Rebase to tzdata-2018g Includes changes for tzdata-2018f. - Volgograd will change from UTC+03 to UTC+04 on 2018-10-28 at 02:00. - Fiji will end DST on 2019-01-13 instead of the 2019-01-20 as previously predicted. - Most of Chile will end DST on the first Saturday in April at 24:00 and restart DST on the first Saturday in September at 24:00. - Morocco will change from UTC+00/+01 to permanent +01 effective 2018-10-27. * Sat Jul 14 2018 Fedora Release Engineering - 2018e-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild * Wed May 16 2018 Patsy Franklin - 2018e-1 - Rebase to tzdata-2018e - North Korea changed from UTC+8:30 to UTC+9 on May 5, 2018. - In this update, the upstream project now defaults to using the "vanguard" data implementation which includes negative DST offsets. Given that the front screen of the bios is displaying the time as local time, presumably that means that the time settings in the bios are local time and the motherboard bios doesn't provide any means to input the time as GMT, hence the bios is not set to GMT. Thinking about the data as displayed by journalctl at boot time, the time stamp on the messages of Nov18 18:16 for a Nov 18 7am boot would make sense if the OS assumed the system clock was GMT and added the local zone offset to the time. Given the fact that my /etc/adjtime has local as the last line, and from my recollection I have not explicitly run the indicated commands that would set that, why is the OS not honouring that specification right from boot commencement? With the time zone data coming from the tzdata package, are you saying that each year when the local governments change when daylight saving starts and ends, that the tzdata package is updated to reflect that? One of the things that might be causing me confusion around this is my belief that the hardware/system clock is the bios time data, is that not correct? If that is correct, are people saying that if I issue the timedatectl command to specify that the RTC is not local, that it will adjust the bios time data to the GMT time that is relevant for the local timezone? regards, Steve ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Network Manager not Retaining Wifi Password
On 19/11/18 1:48 pm, Samuel Sieb wrote: On 11/18/18 1:42 PM, Stephen Morris wrote: I also created a new user and it behaved similarly but slightly differently. When I logged in with the new user I made the mistake of not changing the default so it logged into Gnome, and when Gnome started Networkmanager had a definition for ethernet and my wifi even though they had not been explicitly set up, and the wifi definition had the correct password for my router as the network was connected. Ethernet is normally automatic, no configuration required. By default, NetworkManager stores the password in a keys-* file. I've never tried making a connection not global so I don't know what would happen in that case. I assume that somewhere along the way with your KDE tests, the password got stored. When you used Gnome, it would have the password already. From my experience, at least under KDE, the password is stored in keys-* files if the wifi-security enty in Networkmanager is set to "Store password for all users (not encrypted)" and as the option says the password is in plain text in the keys file. If the option is changed to "Store password for this user only (encrypted)" the keys file is removed and the encrypted password is stored in kwallet. The original issue with the password being blank instead of masked in the wifi definition surfaced when investigating why at KDE start up, after I was prompted for the kwallet password, I was being prompted for the wifi password before the network would activate. Installing pam-kwallet has now stopped the prompting for the kwallet password every time I start KDE. I logged out of Gnome and logged into KDE, and went into the networkmanager wifi definition and deliberately set the wifi password to an incorrect entry from the correct entry that the definition had. The incorrect entry was not retained and neither was the correct entry blanked out like in the original issue, or something was overwriting the incorrect entry with the correct one. It would seem that something isn't working quite right between KDE and NetworkManager. My assumption was it was a Networkmanager is when changing the password setting from "encrypted" to "not encrypted" caused the password to be retained, and then changing the setting from "not encrypted" back to "encrypted" continued to retain the password in the Networkmanager wifi configuration. regards, Steve ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: VPN Interface not Remaining Active With Firewall?
On 11/20/2018 02:07 PM, Stephen Morris wrote: Given that the front screen of the bios is displaying the time as local time, presumably that means that the time settings in the bios are local time and the motherboard bios doesn't provide any means to input the time as GMT, hence the bios is not set to GMT. Thinking about the data as displayed by journalctl at boot time, the time stamp on the messages of Nov18 18:16 for a Nov 18 7am boot would make sense if the OS assumed the system clock was GMT and added the local zone offset to the time. If you want the BIOS clock set to GMT, just enter the time that why and tell Linux that the hardware clock is GMT. It won't matter one bit because the mobo doesn't (AFAIK) use the time for anything and the only reason it's there is so that you don't have to reset the time every time you boot. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: VPN Interface not Remaining Active With Firewall?
On 11/20/18 1:07 PM, Stephen Morris wrote: > On 19/11/18 10:13 am, Ed Greshko wrote: >> On 11/19/18 5:08 AM, Stephen Morris wrote: >>> From recollection, which may not be completely accurate, the Asrock >>> motherboard that I >>> have now is the first motherboard I've had where the bios has not >>> offered a setting to >>> set the system clock to GMT/Local, and I have always set the system >>> clock to local >>> because Windows, which I tri-boot with, used to have issues with the >>> system clock being >>> GMT. Having said this, on this motherboard there isn't any option to >>> change it, the >>> front screen is showing local time and that time is correct for >>> daylight savings time, >>> even though the machine wasn't switched on when >>> daylight savings time kicked in. >>> >>> I also seem to remember that there used to be an option in >>> KDE->System Settings to >>> configure whether or not the system clock was running local or GMT >>> time, which I can't >>> find now. The only setting I can find is to set the timezone and to >>> set the date and >>> time automatically. From memory there used to also be an option in >>> KDE->System Setttings >>> to have the clock maintained by a Network Time Clock where you could >>> also specify the >>> URL to connect to, which I used to have set to an Oceania location, >>> but I can't find that anymore either. >> Think about it for a moment. Does it make any sense for a motherboard >> to have knowledge >> of time zones? >> >> The same motherboard is used all over the world and unless you update >> the BIOS they would >> remain static in their knowledge to time zones. > > I'm not saying the motherboard bios has knowledge of timezones, what I > am saying is that other motherboards I've had have provided the facility > when setting the time in the bios to specify whether the time being > input is local time or GMT time. > > >> I've pointed out where time zone information is kept. Those files are >> provided by the >> tzdata package. Here is the start of the "changelog" for that package. >> >> * Mon Nov 12 2018 Patsy Griffin Franklin - 2018g-1 >> - Rebase to tzdata-2018g >> Includes changes for tzdata-2018f. >> - Volgograd will change from UTC+03 to UTC+04 on 2018-10-28 at 02:00. >> - Fiji will end DST on 2019-01-13 instead of the 2019-01-20 as >> previously predicted. >> - Most of Chile will end DST on the first Saturday in April at 24:00 >> and restart DST on the first Saturday in September at 24:00. >> - Morocco will change from UTC+00/+01 to permanent +01 effective >> 2018-10-27. >> >> * Sat Jul 14 2018 Fedora Release Engineering >> - 2018e-2 >> - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild >> >> * Wed May 16 2018 Patsy Franklin - 2018e-1 >> - Rebase to tzdata-2018e >> - North Korea changed from UTC+8:30 to UTC+9 on May 5, 2018. >> - In this update, the upstream project now defaults to using >> the "vanguard" data implementation which includes negative DST >> offsets. > > Given that the front screen of the bios is displaying the time as local > time, presumably that means that the time settings in the bios are local > time and the motherboard bios doesn't provide any means to input the > time as GMT, hence the bios is not set to GMT. Thinking about the data > as displayed by journalctl at boot time, the time stamp on the messages > of Nov18 18:16 for a Nov 18 7am boot would make sense if the OS assumed > the system clock was GMT and added the local zone offset to the time. > > Given the fact that my /etc/adjtime has local as the last line, and from > my recollection I have not explicitly run the indicated commands that > would set that, why is the OS not honouring that specification right > from boot commencement? > > With the time zone data coming from the tzdata package, are you saying > that each year when the local governments change when daylight saving > starts and ends, that the tzdata package is updated to reflect that? > > One of the things that might be causing me confusion around this is my > belief that the hardware/system clock is the bios time data, is that not > correct? If that is correct, are people saying that if I issue the > timedatectl command to specify that the RTC is not local, that it will > adjust the bios time data to the GMT time that is relevant for the local > timezone? What happens is the SYSTEM clock (which is what the OS uses for internal stuff and is expected to be in UTC) is set to the BIOS clock at boot. AFAIK, the variable in /etc/adjtime is not looked at as /etc may not have been mounted yet (don't know this for sure, but it seems to work like that). From then on, the BIOS clock is ignored as far as the OS is concerned. NTP clients (chronyd) keep the SYSTEM clock synchronized to UTC. You have the option of resetting the BIOS clock to the SYSTEM clock via the hwclock command, and setting the LOCAL or UTC flag on that command will set the BIOS clock appropria
Re: VPN Interface not Remaining Active With Firewall?
On 11/21/18 5:07 AM, Stephen Morris wrote: > > > Given that the front screen of the bios is displaying the time as local time, > presumably > that means that the time settings in the bios are local time and the > motherboard bios > doesn't provide any means to input the time as GMT, hence the bios is not set > to GMT. Let me try this one last time. And it will be one last time. I can tell you how to set your system up to get consistent log entries. It will be your choice to do it or not. You have already said that the motherboard has no concept of time zones. That is totally irrelevant. YOU know what time it is and YOU know what time zone you are in! I look at my mobile phone and see it is 05:55 on November 21. I know I am in GMT+8. So, GMT time is now 21:55 on November 20. So, I go to my BIOS screen and enter 21:55 as the time and November 20 as the date. The motherboard clock is NOW set to GMT! It matter not one lick if the MB has an idea of any time zone! Step one Done. > Thinking about the data as displayed by journalctl at boot time, the time > stamp on the > messages of Nov18 18:16 for a Nov 18 7am boot would make sense if the OS > assumed the > system clock was GMT and added the local zone offset to the time. > > Given the fact that my /etc/adjtime has local as the last line, and from my > recollection > I have not explicitly run the indicated commands that would set that, why is > the OS not > honouring that specification right from boot commencement? Set that last line to UTC. You have now told the O/S that the HW clock is set to UTC/GMT. So now the O/S knows what you know. Step two Done. Make sure the the link /etc/localtime points to a correct time zone for where your system is physically located. [egreshko@meimei etc]$ ll /etc/localtime lrwxrwxrwx. 1 root root 33 Dec 21 2017 /etc/localtime -> ../usr/share/zoneinfo/Asia/Taipei for ME. (you can use timedatectl to show/set) Step three Done. Reboot Done. You will now get correct and consistent date/time stamps in your logs going forwad. Previous timestamps won't be fixed. Don't want to do that. Well, you'll be in the same situation you are now and that will be that. > > With the time zone data coming from the tzdata package, are you saying that > each year > when the local governments change when daylight saving starts and ends, that > the tzdata > package is updated to reflect that? Look at the changelog for the package as I showed you. rpm -q --changelog tzdata and you will see the dates it was updated and why it was updated. The answer to your question is obvious. -- Right: I dislike the default color scheme Wrong: What idiot picked the default color scheme ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: VPN Interface not Remaining Active With Firewall?
On 11/20/18 2:09 PM, Ed Greshko wrote: > On 11/21/18 5:07 AM, Stephen Morris wrote: >> >> >> Given that the front screen of the bios is displaying the time as local >> time, presumably >> that means that the time settings in the bios are local time and the >> motherboard bios >> doesn't provide any means to input the time as GMT, hence the bios is not >> set to GMT. > > Let me try this one last time. And it will be one last time. I can tell you > how to set > your system up to get consistent log entries. It will be your choice to do > it or not. > > You have already said that the motherboard has no concept of time zones. > That is totally > irrelevant. YOU know what time it is and YOU know what time zone you are in! > > I look at my mobile phone and see it is 05:55 on November 21. I know I am in > GMT+8. So, > GMT time is now 21:55 on November 20. So, I go to my BIOS screen and enter > 21:55 as the > time and November 20 as the date. The motherboard clock is NOW set to GMT! > It matter not > one lick if the MB has an idea of any time zone! > > Step one Done. > >> Thinking about the data as displayed by journalctl at boot time, the time >> stamp on the >> messages of Nov18 18:16 for a Nov 18 7am boot would make sense if the OS >> assumed the >> system clock was GMT and added the local zone offset to the time. >> >> Given the fact that my /etc/adjtime has local as the last line, and from my >> recollection >> I have not explicitly run the indicated commands that would set that, why is >> the OS not >> honouring that specification right from boot commencement? > > Set that last line to UTC. You have now told the O/S that the HW clock is > set to > UTC/GMT. So now the O/S knows what you know. > > Step two Done. > > Make sure the the link /etc/localtime points to a correct time zone for where > your system > is physically located. > > [egreshko@meimei etc]$ ll /etc/localtime > lrwxrwxrwx. 1 root root 33 Dec 21 2017 /etc/localtime -> > ../usr/share/zoneinfo/Asia/Taipei > > for ME. > > (you can use timedatectl to show/set) > > Step three Done. > > Reboot > > Done. > > You will now get correct and consistent date/time stamps in your logs going > forwad. > Previous timestamps won't be fixed. Don't want to do that. Well, you'll be > in the same > situation you are now and that will be that. > > >> >> With the time zone data coming from the tzdata package, are you saying that >> each year >> when the local governments change when daylight saving starts and ends, that >> the tzdata >> package is updated to reflect that? > > Look at the changelog for the package as I showed you. > > rpm -q --changelog tzdata > > and you will see the dates it was updated and why it was updated. The answer > to your > question is obvious. And to make it clear, Linux expects the SYSTEM clock to be in UTC, Windows expects it to be in local time. The SYSTEM clock is set to the BIOS clock at boot time for both OSes. There is really no (clean) way to make these two disparate things live together. There is a way to bugger Windows to use a UTC clock via a registry entry, but it's a kludge. Choose which one (Windows or Linux) is your primary OS, and set your BIOS clock accordingly (localtime for Windows, UTC for Linux). Linux will handle a localtime BIOS clock better. If your BIOS clock is in local time (as Windows wants) and you boot Linux, the log entries will have the incorrect time until chronyd drags the SYSTEM clock into sync with UTC. The log entries will be correct from that point onwards. So, use journalctl to look for log entries for chronyd: journalctl -b -u chronyd And look for the lines that indicate the clock was reset: chronyd<[pid]>: System clock was stepped by seconds Log entries before that assume your local time is UTC, will be displayed adjusted for your local timezone and will be off by whatever your timezone is. Entries after that will be based on the real UTC, displayed as your local timezone and will be correct. That's just the way it is (unfortunately). -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 226437340 Yahoo: origrps2 - -- -Change is inevitable, except from a vending machine.- -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: VPN Interface not Remaining Active With Firewall?
On 11/21/18 7:02 AM, Rick Stevens wrote: > That's just the way it is (unfortunately). And one of the myriad of reasons I don't dual boot with Windows. VM's are good enough for the few times I've got no choice in the matter. -- Right: I dislike the default color scheme Wrong: What idiot picked the default color scheme ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: df -H shows irritating values
On Tue, 20 Nov 2018 08:14:43 -0800 Samuel Sieb wrote: > On 11/20/18 5:45 AM, Frank Elsner wrote: > > I have a 64GB USB-Stick inserted to my Fritz!Box which is available as a > > SMB mount point. > > > > When I mount it "df -H" shows > > > > Filesystem Size Used Avail . Mounted on > > .. > > //fritz.box/nil123G38G86G 31% /nas > > What does "df -h" show? Filesystem Size Used Avail Use% Mounted on .. //fritz.box/nil 115G 38G 77G 33% /nas Greetings, Frank ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: df -H shows irritating values
On 11/20/18 10:49 PM, Frank Elsner wrote: On Tue, 20 Nov 2018 08:14:43 -0800 Samuel Sieb wrote: On 11/20/18 5:45 AM, Frank Elsner wrote: I have a 64GB USB-Stick inserted to my Fritz!Box which is available as a SMB mount point. When I mount it "df -H" shows Filesystem Size Used Avail . Mounted on .. //fritz.box/nil123G38G86G 31% /nas What does "df -h" show? Filesystem Size Used Avail Use% Mounted on .. //fritz.box/nil 115G 38G 77G 33% /nas In that case, the -H numbers are not out of line. You need to figure out why the smb mount is advertising a larger space than it should be. Can you get a shell on the box to check what it thinks the size is? ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: df -H shows irritating values
On Tue, 20 Nov 2018 23:26:29 -0800 Samuel Sieb wrote: > On 11/20/18 10:49 PM, Frank Elsner wrote: > > On Tue, 20 Nov 2018 08:14:43 -0800 Samuel Sieb wrote: > >> On 11/20/18 5:45 AM, Frank Elsner wrote: > >>> I have a 64GB USB-Stick inserted to my Fritz!Box which is available as a > >>> SMB mount point. > >>> > >>> When I mount it "df -H" shows > >>> > >>> Filesystem Size Used Avail . Mounted on > >>>.. > >>> //fritz.box/nil123G38G86G 31% /nas > >> > >> What does "df -h" show? > > > > Filesystem Size Used Avail Use% Mounted on > > .. > > //fritz.box/nil 115G 38G 77G 33% /nas > > In that case, the -H numbers are not out of line. You need to figure > out why the smb mount is advertising a larger space than it should be. Exactly that was the initial question. > Can you get a shell on the box to check what it thinks the size is? On what box? The client or the server? On the server the size is 56,79 GB. Greetings, Frank ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
