Error getting authority error initializing authority could not connect no such file or directory

ROSAForum

Forum about ROSA Linux Distros

• Темы без ответов
• Активные темы
• Поиск
• Наша команда

Что-то поломалось [Решено]

Что-то поломалось [Решено]

Сообщение va9(2) » 20 окт 2015, 08:41

На ноуте установлена 64 битная система с кедами.

Далее. Загружаюсь с живой флешки на которой R6 32 битная с кедами. По быстрому настраиваю тачпад и меняю тему рабочего стола. Лезу в дельфин, чтобы поменять фон рабочего стола и обнаруживаю отсутствие хомяка.

Как мне все вернуть обратно? Особенно важна информация на хомяке.

Re: Что-то поломалось

Сообщение VictorR2007 » 20 окт 2015, 09:26

Re: Что-то поломалось

Сообщение va9(2) » 20 окт 2015, 09:39

Re: Что-то поломалось

Сообщение VictorR2007 » 20 окт 2015, 09:48

Re: Что-то поломалось

Сообщение va9(2) » 20 окт 2015, 10:37

Не загрузилась система. Пишет «Error getting authority: Error initializing authority: Could not connect: No such file or directory (g-io-error-quark, 1)», и снова строки про пароль корня для чего-то там или ctrl+d для продолжения.

gparted у меня жд вот так видит:

и кнопка проверить на ошибки недоступна.

пс. Пару месяцев назад заходит в gparted при стабильно работающей системе и он также показывал жд как не размеченный.

Re: Что-то поломалось

Сообщение VictorR2007 » 20 окт 2015, 10:59

va9(2) писал(а): Не загрузилась система. Пишет «Error getting authority: Error initializing authority: Could not connect: No such file or directory (g-io-error-quark, 1)», и снова строки про пароль корня для чего-то там или ctrl+d для продолжения.

пс. Пару месяцев назад заходит в gparted при стабильно работающей системе и он также показывал жд как не размеченный.

Источник

Authoritative resource for: Error getting authority: Error initializing authority: Could not connect: No such file or directory (g-io-error-quark, 1)

This is for Kubuntu 14.04 with LVM and UEFI. The system will not boot normally. I can get to the root prompt in rescue mode.

The error happened yesterday. I did a normal update (apt-get dist-upgrade), but did not restart the computer right away due to having some applications open. Later the monitors went to sleep (just the monitors, not the system). However, I could not get out of the blank screen mode with anything I tried (except switching to a virtual console via ALT-F1). So I rebooted the system. But it would not boot normally. I get a completely blank screen. I can switch to a virtual console (or I can boot in rescue mode). But I am not able to boot normally (into the GUI).

It appears that the exact same error can be produced in many different situations.

Having reviewed similar questions, I’m not finding any solution.

What are all the known issues that can cause this error message? (I’ll test them one-by-one until I find the solution.) In general, it would be nice to have an authoritative resource for this very confusing error.

See my screen picture:

There are 3 partitions: sda1, sda2, sda3
sda1 is /boot/efi
sda2 is /boot
sda3 is the LVM-based file system. It has 2 LV’s (one is the root fs and one is swap).

1 Answer 1

Searching the Internet leads to the conclusion that the exact same error can be produced in many different situations. That’s true.

However, there is a single underlying issue. Understanding it will help clarify the situation. What is happening is that systemd is dropping into emergency mode by design. The developers consider this correct behavior, not a bug.

The message is from polkit. The recommended steps after receiving this message are to drop into a root shell and run the following command:

In particular, look for fstab entries that reference non-existent devices. Or, if it is a device that needs to remain listed in fstab, consider adding the nofail boot option to it. (Some recommend adding nofail to all fstab entries now.)

In this thread, giulioo gives an acerbic set of steps for recovering from this error:

2) Let’s say you realize fstab was the problem, you then correct the problem in fstab (e.g., by adding nofail or by removing a problematic device listing) and press CTRL-D, and what happens? This happens:

The system then stalls for another 60 secs, and then you are again presented with the emergency message.

You then hopefully realize that maybe fstab-generator early in the boot created unit files from fstab and systemd is using the «old» unit files instead of the updated fstab.

But this time the system won’t stall, so you again press press CTRL-D and you get:

Finally, this time after a few seconds the system will boot succesfully.

Источник

Arch Linux

You are not logged in.

#1 2012-11-12 23:57:17

[SOLVED] «systemctl poweroff» permissions error

Previously I could run

and it would shut down the system without prompting for root password as long as no-one else was logged in. Now I get:

journalctl tells me:

so it looks like it’s some problem with systemd-logind.service:

And /etc/systemd/logind.conf says:

Anyone got any ideas? Thanks in advance!

Last edited by Snark1994 (2012-11-18 22:41:06)

#2 2012-11-13 16:13:04

Re: [SOLVED] «systemctl poweroff» permissions error

Check if your session is registered as active with loginctl show-session an if there are multiple sessions.

#3 2012-11-13 16:31:52

Re: [SOLVED] «systemctl poweroff» permissions error

Yes and no respectively:

Last edited by Snark1994 (2012-11-13 16:32:16)

#4 2012-11-13 17:25:20

Re: [SOLVED] «systemctl poweroff» permissions error

I’ve seen recently that slim seems to be having issues with logind and systemd. If you logout and log back in and loginctl list-sessions you’ll likely see two sessions listed. Slim seems to be having problems dealing with sessions properly. My only suggestion would be to try xdm instead as it doesn’t appear to have these issues. It’s still lightweight and doesn’t have the recurring problems slim seems to have. My only suggestion. Sorry.

Time is a great teacher, but unfortunately it kills all its pupils . — Louis Hector Berlioz

#5 2012-11-13 17:38:46

Re: [SOLVED] «systemctl poweroff» permissions error

Ah, okay. No problems then, I’ll just change to xdm.

I can confirm the two session symptom. Do we know if this is a slim bug, or an Arch bug? And if the former, has someone reported it?

#6 2012-11-13 17:48:58

Re: [SOLVED] «systemctl poweroff» permissions error

There are a couple of bugs filed against slim concerning systemd. FS#32380 is relevant in that if slim doesn’t finish exiting processes, the sessions don’t get closed so it looks like it’s already being handled.

BTW, straight xorg-xdm is butt ugly. xdm-archinux in community is a big improvement. It also adds reboot and poweroff buttons.

Last edited by bgc1954 (2012-11-13 17:50:08)

Time is a great teacher, but unfortunately it kills all its pupils . — Louis Hector Berlioz

#7 2012-11-14 00:26:58

Re: [SOLVED] «systemctl poweroff» permissions error

Okay, actually that doesn’t fix the problem. Even with XDM I get the same «Error getting authority: blah blah» error that I quoted in my first post. «list-sessions»/»show-session» show 1 user and Active=yes respectively.

#8 2012-11-16 16:48:22

Re: [SOLVED] «systemctl poweroff» permissions error

Maybe a shot in the dark but you do have systemd-sysvcompat installed? And there’s nothing still trying to use consolekit in your .xinitrc? How about systemctl status polkit.service?

Time is a great teacher, but unfortunately it kills all its pupils . — Louis Hector Berlioz

#9 2012-11-16 17:23:57

Re: [SOLVED] «systemctl poweroff» permissions error

Yes, I’ve got systemd-sysvcompat installed.

And there’s nothing still trying to use consolekit in your .xinitrc?

How would I work that out? Or is it just a case of looking at the docs for each programme?

Am I correct in thinking that «inactive (dead)» is a bad sign?

Last edited by Snark1994 (2012-11-16 17:24:27)

#10 2012-11-16 18:00:31

Re: [SOLVED] «systemctl poweroff» permissions error

AS far as your .xinitrc, I just meant that have you got a simple «exec windowmanager» containing no dbus-launch or ck-session-launch entries. Several suggestions to launch dbus, etc. is to copy /etc/skel/.xinitrc to

/.xinitrc and modify to launch your wm.

Yes, having a dead polkit.service will cause you just the problems you’re describing. There are a few threads on this in the forum but I can’t think of one off the top of my head so maybe a forum search on polkit.service will find you what you’re looking for.

Time is a great teacher, but unfortunately it kills all its pupils . — Louis Hector Berlioz

#11 2012-11-16 23:43:45

Re: [SOLVED] «systemctl poweroff» permissions error

I couldn’t find any threads with solutions, either on google or using forum search. However, if I try to run polkitd manually I get:

. so it sounds like polkitd has problems independent of systemd. http://lists.freedesktop.org/archives/p … 00367.html references the same problem, but the file /opt/var/run/dbus/system_bus_socket doesn’t exist for me.

#12 2012-11-17 01:44:42

Re: [SOLVED] «systemctl poweroff» permissions error

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

#13 2012-11-17 09:44:28

Re: [SOLVED] «systemctl poweroff» permissions error

Nope, don’t even have a /var/run/dbus directory.

I have /usr/lib/systemd/system/dbus.socket but according to «locate», no files named «system-bus-socket» in the filesystem ( also ran «find /var -iname ‘system-bus-socket’» just in case, but no luck there either).

I found http://lists.freedesktop.org/archives/d … 09206.html: I don’t have messagebus user/group, but I do have dbus user/group. Is this the source of my problem, do you think?

[EDIT]Nope, I added a messagebus user and group and the problem persists. [/EDIT]

Last edited by Snark1994 (2012-11-17 15:53:25)

#14 2012-11-17 16:04:23

Re: [SOLVED] «systemctl poweroff» permissions error

Hm, I’m getting closer — I’ve found system-bus-socket, it was in /run/dbus. I didn’t even know I had a top-level /run directory. However, running:

doesn’t help at all.

Also, I note that in /etc/dbus-1/system.conf has

#15 2012-11-17 18:23:27

Re: [SOLVED] «systemctl poweroff» permissions error

to check the status of dbus. Did you try and copy /etc/skel/.xinitrc to your home directory like I suggested before? It looks like dbus isn’t running or responding properly for some reason. I think I read somewhere that someone was still using dbus-launch in his .xinitrc and it worked for him.

As far as groups are concerned the systemd wiki claims you don’t need to be in groups in most cases.

Time is a great teacher, but unfortunately it kills all its pupils . — Louis Hector Berlioz

#16 2012-11-17 19:27:30

Re: [SOLVED] «systemctl poweroff» permissions error

I haven’t,, but as you can see I have nothing the /etc/skel/.xinitrc doesn’t have.

I also tried swapping the last line for

but to no avail (exactly the same symptoms when trying to start polkitd manually, or trying to systemctl poweroff without root priveliges).

#17 2012-11-17 21:33:59

Re: [SOLVED] «systemctl poweroff» permissions error

A while ago I seem to remember having issues with polkit and someone suggested reinstalling on another post. When I tried, I found that polkit didn’t install properly as there was a goup id number conflict. It turned out I had an old install of gdm and it ws using the same group id that polkit was trying to use during install. After I got rid of gdm and did a reinstall of polkit, it worked properly. Just a shot in the dark really. See https://bbs.archlinux.org/viewtopic.php?pid=1187801

Last edited by bgc1954 (2012-11-18 16:02:58)

Time is a great teacher, but unfortunately it kills all its pupils . — Louis Hector Berlioz

#18 2012-11-18 00:50:31

Re: [SOLVED] «systemctl poweroff» permissions error

You said that you have /run/dbus but not /var/run/dbus?

There’s your problem. (Well, one of them, anyway.)

/var/run should be a symlink to /run.

If that is not the case on your machine, either your system is rather out of date or something has gone rather wrong somewhere.

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

#19 2012-11-18 17:28:25

Re: [SOLVED] «systemctl poweroff» permissions error

Aha! cfr has it. Perhaps I messed up https://www.archlinux.org/news/filesyst … equired-1/. (or it became messed up when I removed initscripts? Dunno.)

I’ve rectified the situation, and polkitd starts correctly. I’ll reboot now and see if the problem’s fixed.

Last edited by Snark1994 (2012-11-18 22:40:35)

#20 2012-11-18 22:40:40

Re: [SOLVED] «systemctl poweroff» permissions error

Yes, that fixed the problem. Thank you very much everyone for your help, and especially cfr for the solution. Diolch yn fawr!

#21 2012-11-19 00:17:49

Re: [SOLVED] «systemctl poweroff» permissions error

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

#22 2012-12-31 23:49:56

Re: [SOLVED] «systemctl poweroff» permissions error

I have the same problem.

[root@zoulou run]# pwd
/var/run
[root@zoulou run]# ls
[root@zoulou run]# cd /run/dbus/
[root@zoulou dbus]# ls
system_bus_socket
[root@zoulou dbus]# ls -lha
total 0
drwxr-xr-x 2 root root 60 Jan 1 00:04 .
drwxr-xr-x 17 root root 400 Jan 1 00:04 ..
srw-rw-rw- 1 root root 0 Jan 1 00:04 system_bus_socket
[root@zoulou dbus]# file system_bus_socket
system_bus_socket: socket
[root@zoulou dbus]#

But I have installed Arch let’s say. two months ago so I have a complete-full systemd «compliant OS.
It was working fine until this evening, I was just googling and reading newspaper and sudenly Conky display a log of messages from /var/log/messages.log !

My Arch is up to date.
I have tried to restart a couple of time but nothing change.

Do you have an idea ?

Dec 31 21:10:20 zoulou dbus-daemon[945]: dbus[945]: [system] Activating systemd to hand-off: service name=’org.freedesktop.UPower’ unit=’upower.service’
Dec 31 21:10:20 zoulou dbus[945]: [system] Activating systemd to hand-off: service name=’org.freedesktop.UPower’ unit=’upower.service’
Dec 31 21:10:45 zoulou dbus-daemon[945]: dbus[945]: [system] Failed to activate service ‘org.freedesktop.UPower’: timed out
Dec 31 21:10:45 zoulou dbus[945]: [system] Failed to activate service ‘org.freedesktop.UPower’: timed out
Dec 31 21:10:45 zoulou dbus[945]: [system] Failed to activate service ‘org.freedesktop.systemd1’: timed out
Dec 31 21:10:45 zoulou dbus-daemon[945]: dbus[945]: [system] Failed to activate service ‘org.freedesktop.systemd1’: timed out
Dec 31 21:10:45 zoulou dbus-daemon[945]: process 945: arguments to dbus_message_set_reply_serial() were incorrect, assertion «reply_serial != 0» failed in file dbus-message.c line 1070.
Dec 31 21:10:45 zoulou dbus-daemon[945]: This is normally a bug in some application using the D-Bus library.
Dec 31 21:10:45 zoulou dbus-daemon[945]: D-Bus not built with -rdynamic so unable to print a backtrace
Dec 31 21:10:45 zoulou systemd[1]: dbus.service: main process exited, code=killed, status=6/ABRT
Dec 31 21:10:45 zoulou systemd[1]: Unit dbus.service entered failed state
Dec 31 21:10:45 zoulou systemd[1]: systemd-logind.service: main process exited, code=exited, status=1/FAILURE
Dec 31 21:10:45 zoulou systemd[1]: Unit systemd-logind.service entered failed state
Dec 31 21:10:45 zoulou systemd[1]: systemd-logind.service holdoff time over, scheduling restart.
Dec 31 21:10:45 zoulou systemd[1]: Stopping Login Service.
Dec 31 21:10:45 zoulou systemd[1]: Starting Login Service.
Dec 31 21:10:45 zoulou systemd[1]: Starting D-Bus System Message Bus.
Dec 31 21:10:45 zoulou systemd[1]: Started D-Bus System Message Bus.
Dec 31 21:10:45 zoulou systemd[1]: Failed to open private bus connection: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
Dec 31 21:10:47 zoulou dbus-daemon[954]: dbus[954]: [system] Activating systemd to hand-off: service name=’org.freedesktop.UPower’ unit=’upower.service’
Dec 31 21:10:47 zoulou dbus[954]: [system] Activating systemd to hand-off: service name=’org.freedesktop.UPower’ unit=’upower.service’
Dec 31 21:11:12 zoulou dbus-daemon[954]: dbus[954]: [system] Failed to activate service ‘org.freedesktop.UPower’: timed out
Dec 31 21:11:12 zoulou dbus[954]: [system] Failed to activate service ‘org.freedesktop.UPower’: timed out
Dec 31 21:11:12 zoulou dbus[954]: [system] Failed to activate service ‘org.freedesktop.systemd1’: timed out
Dec 31 21:11:12 zoulou dbus-daemon[954]: dbus[954]: [system] Failed to activate service ‘org.freedesktop.systemd1’: timed out
Dec 31 21:11:12 zoulou dbus-daemon[954]: process 954: arguments to dbus_message_set_reply_serial() were incorrect, assertion «reply_serial != 0» failed in file dbus-message.c line 1070.
Dec 31 21:11:12 zoulou dbus-daemon[954]: This is normally a bug in some application using the D-Bus library.
Dec 31 21:11:12 zoulou dbus-daemon[954]: D-Bus not built with -rdynamic so unable to print a backtrace
Dec 31 21:11:12 zoulou systemd[1]: dbus.service: main process exited, code=killed, status=6/ABRT
Dec 31 21:11:12 zoulou systemd[1]: Unit dbus.service entered failed state
Dec 31 21:11:12 zoulou systemd[1]: systemd-logind.service: main process exited, code=exited, status=1/FAILURE
Dec 31 21:11:12 zoulou systemd[1]: Unit systemd-logind.service entered failed state
Dec 31 21:11:12 zoulou systemd[1]: systemd-logind.service holdoff time over, scheduling restart.
[root@zoulou dbus]#

Life is not linear.
————
Arch power !

Источник

Что-то поломалось [Решено]

# Entry for /dev/sda1 :
UUID=75a28304-cdd3-446d-9d7a-53f18a6834fb / ext4 noatime,acl 1 1
# Entry for /dev/sda6 :
UUID=d5fe2a77-6f3b-4f8b-a6b0-ba2c6a28f0b8 /home ext4 acl,noatime 1 2
none /proc proc defaults 0 0
# Entry for /dev/sda5 :
UUID=04cf07ec-d78e-420c-b344-39ace0be6dd4 swap swap defaults 0 0

# fsck -a
fsck из util-linux 2.24.2
/dev/sda1 is mounted.
e2fsck: Cannot continue, aborting.

live@localhost ~ $ su -
localhost ~ # fsck -a
fsck from util-linux 2.24.2
localhost ~ # fsck -a /dev/sda1
fsck from util-linux 2.24.2
/dev/sda1: Superblock last mount time is in the future.
        (by less than a day, probably due to the hardware clock being incorrectly set)  FIXED.
/dev/sda1: Superblock last write time is in the future.
        (by less than a day, probably due to the hardware clock being incorrectly set).  FIXED.
/dev/sda1: clean, 347293/2166912 files, 3147870/8650752 blocks
localhost ~ #

localhost ~ # fsck -a /dev/sda1
fsck from util-linux 2.24.2
/dev/sda1: clean, 347293/2166912 files, 3147870/8650752 blocks
localhost ~ #

localhost ~ # fsck -a /dev/sda5
fsck from util-linux 2.24.2
fsck: fsck.swap: not found
fsck: error 2 while executing fsck.swap for /dev/sda5
localhost ~ # fsck -a /dev/sda6
fsck from util-linux 2.24.2
fsck.ext2: No such file or directory while trying to open /dev/sda6
Possibly non-existent device?
localhost ~ # 

# Entry for /dev/sda6 :
UUID=d5fe2a77-6f3b-4f8b-a6b0-ba2c6a28f0b8 /home ext4 acl,noatime 1 2
none /proc proc defaults 0 0
# Entry for /dev/sda5 :
UUID=04cf07ec-d78e-420c-b344-39ace0be6dd4 swap swap defaults 0 0

 # Entry for /dev/sda6 :
    # UUID=d5fe2a77-6f3b-4f8b-a6b0-ba2c6a28f0b8 /home ext4 acl,noatime 1 2
    none /proc proc defaults 0 0
    # Entry for /dev/sda5 :
     #UUID=04cf07ec-d78e-420c-b344-39ace0be6dd4 swap swap defaults 0 0

# Entry for /dev/sda6 :
#UUID=d5fe2a77-6f3b-4f8b-a6b0-ba2c6a28f0b8 /home ext4 acl,noatime 1 2
#none /proc proc defaults 0 0
# Entry for /dev/sda5 :
#UUID=04cf07ec-d78e-420c-b344-39ace0be6dd4 swap swap defaults 0 0

Environment

Windows build number: 19041.572
Your Distribution version: Kali Rolling (currently on 2020.3)
Whether the issue is on WSL 2 and/or WSL 1: WSL 2

Steps to reproduce

The pkexec command, when used to run at least some other commands, returns Error getting authority: Error initializing authority: Could not connect: No such file or directory. This was discovered using Wireshark in Kali Linux (on WSL 2) — the «start menu» shortcut for Wireshark runs pkexec wireshark, and does not function. However, running sudo wireshark from the command line works as expected, so the issue does not lie with Wireshark. For ease of testing, the error also appears with pkexec ls.

This was tested in Kali Linux, and has not yet been verified for other WSL distributions.

Expected behavior

$ pkexec wireshark
[Wireshark starts, printing status messages in the process]

Actual behavior

$ pkexec wireshark
Error getting authority: Error initializing authority: Could not connect: No such file or directory

When I was using the Intranet GitLAB warehouse this morning, I found that the page could not be opened and SSH could not be connected.
Connected to the monitor in the machine room, the following errors were found:

Error getting authority: Error initializing authority: Could not connect: No such file or directory (g-io-error-quark, 1)

Enter the root password to enter the shell interface.
As prompted, use the command to view the log

# journalctl -xb -p3
-- Logs begin at Tue 2017-09-05 09:34:14 CST, end at Tue 2017-09-05 10:15:57 CST. --
.... Omitted content
Sep 05 09:34:18 localhost.localdomain kernel: :megaswr[ahci]: polling for interrupt status timed out for port=1, slot=0
Sep 05 09:34:18 localhost.localdomain kernel: :megasr[ahci]: warning PortReset called for port[1]
Sep 05 09:34:18 localhost.localdomain kernel: :megasr[ahci]: device on port:[1] online:[0x133] [0] milliseconds after reset
Sep 05 09:34:25 localhost.localdomain kernel: :megaswr[ahci]: polling for interrupt status timed out for port=1, slot=0
Sep 05 09:34:25 localhost.localdomain kernel: :megaswr[ahci]:Trouble port=1, slot=0
Sep 05 09:34:25 localhost.localdomain kernel: :megaswr[osl]: breakpoint called
Sep 05 09:34:25 localhost.localdomain kernel: :megasr[ahci]: Device:[2:INTEL SSDSC2BW48] NCQ:[Yes] Queue Depth:[0x20] capacity=0x37e436b0
Sep 05 09:34:25 localhost.localdomain kernel: :megasr[ahci]: Device:[3:INTEL SSDSC2BW48] NCQ:[Yes] Queue Depth:[0x20] capacity=0x37e436b0
Sep 05 09:34:25 localhost.localdomain kernel: :megasr[ahci]: Device:[4:ST9500620NS     ] NCQ:[Yes] Queue Depth:[0x20] capacity=0x3a386030
Sep 05 09:34:25 localhost.localdomain kernel: :megasr[ahci]: Device:[5:ST9500620NS     ] NCQ:[Yes] Queue Depth:[0x20] capacity=0x3a386030
Sep 05 09:34:25 localhost.localdomain kernel: :megasr: raid 10 logical drive is degraded, is not initialized, has 2 spans, and has a size of 0x6f869000 sectors
Sep 05 09:34:25 localhost.localdomain kernel: :megasr: raid 1 logical drive is online, is not initialized, has 2 drives, and has a size of 0x3a175800 sectors.
Sep 05 09:34:25 localhost.localdomain kernel: :megasr[raid_key]: [ ] RAID5 support    [ ] SAS drive support
Sep 05 09:35:57 localhost.localdomain systemd[1]: Timed out waiting for device dev-sdc1.device.

In the logs, you see a problem with the Dev-SDC1 device.
View disk partitions

# fdisk  -l

Disk /dev/sdb: 499.0 GB, 498999492608 bytes, 974608384 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes/512 bytes
I/O size (minimum/optimal): 512 bytes/512 bytes
Disk label type: dos
Disk identifier: 0xfcae2784

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048  1949216767   974607360   83  Linux
WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.

Disk /dev/sda: 958.0 GB, 957997907968 bytes, 1871089664 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes/512 bytes
I/O size (minimum/optimal): 512 bytes/512 bytes
Disk label type: gpt


#         Start          End    Size  Type            Name
 1         2048       411647    200M  EFI System      EFI System Partition
 2       411648       821247    200M  Microsoft basic 
 3       821248   1871087615  891.8G  Linux LVM       

Disk /dev/mapper/cl-root: 946.8 GB, 946834767872 bytes, 1849286656 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes/512 bytes
I/O size (minimum/optimal): 512 bytes/512 bytes


Disk /dev/mapper/cl-swap: 10.7 GB, 10737418240 bytes, 20971520 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes/512 bytes
I/O size (minimum/optimal): 512 bytes/512 bytes

Obviously, the SDC is gone. I just remember that when I installed the system, I inserted an extra USB flash disk. At that time, the USB flash disk was identified as SDB and this disk was identified as SDC.
Check out fSTAB to prove it.

# cat /etc/fstab 

#
# /etc/fstab
# Created by anaconda on Tue Aug  8 13:10:48 2017
#
# Accessible filesystems, by reference, are maintained under ‘/dev/disk‘
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/cl-root    /                      xfs     defaults        0 0
UUID=a51fd6f8-a756-4e8f-ba44-5589fb99861e /boot                   xfs     defaults        0 0
UUID=7D74-6C54          /boot/efi               vfat    umask=0077,shortname=winnt 0 0
/dev/mapper/cl-swap     swap                    swap    defaults        0 0
/dev/sdc1 /data ext4 defaults 0 0

It looks like you are changing the name of the disk you are writing to UUID.

# blkid 
/dev/sdc1: UUID="ab4c28b5-1708-483c-973a-40f91d320a9d" TYPE="ext4" 
...

The modified FSTAB is

# cat /etc/fstab 

#
# /etc/fstab
# Created by anaconda on Tue Aug  8 13:10:48 2017
#
# Accessible filesystems, by reference, are maintained under ‘/dev/disk‘
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/cl-root    /                      xfs     defaults        0 0
UUID=a51fd6f8-a756-4e8f-ba44-5589fb99861e /boot                   xfs     defaults        0 0
UUID=7D74-6C54          /boot/efi               vfat    umask=0077,shortname=winnt 0 0
/dev/mapper/cl-swap     swap                    swap    defaults        0 0
UUID=ab4c28b5-1708-483c-973a-40f91d320a9d /data ext4 defaults 0 0

Try to restart daemon, same error still pops up.

# systemctl daemon-reload
Error getting authority. Error initializing authority: Could not connect: No such file or directory  (g-io-error-quark, 1)

Exit the shell and the error pops up again.

Error getting authority: Error initializing authority: Could not connect: No such file or directory (g-io-error-quark, 1)

Never mind, wait a few seconds, the system is ready to start normally.