Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

DietPi-Software | Syncthing: Service fails due to permission issue #3180

Closed
ralban opened this issue Oct 20, 2019 · 8 comments
Closed

DietPi-Software | Syncthing: Service fails due to permission issue #3180

ralban opened this issue Oct 20, 2019 · 8 comments
Labels
Bug 🐞 Solution available 🥂 Definite solution has been done
Milestone
v6.27

Comments

@ralban
Copy link

ralban commented Oct 20, 2019 •
edited by MichaIng
Loading

ADMIN EDIT

Solution

chown -R dietpi:dietpi /mnt/dietpi_userdata/syncthing*
systemctl restart syncthing

Details:

Steps to reproduce:

  1. run dietpi-PREP script on fresh Debian 10.1 install
  2. install SyncThing
  3. Attempt to access http://IP-ADDRESS:8384

Expected behaviour:

  • SyncThing should load in my browser

Actual behaviour:

  • SyncThing does not load

Extra details:

  • BugReport submitted

Additional logs:

  • BugReport submitted
@MichaIng
Copy link
Owner

@ralban
Many thanks for your report.

If you submitted a bugreport, please paste the ID here: mawk 'NR==5' /DietPi/dietpi/.hw_model

@ralban
Copy link
Author

ralban commented Oct 21, 2019

b9746b36-f05f-42ca-bc73-e65d756dda33

@mowestusa
Copy link

I have the same issue, just installed syncthing yesterday, and I have been unable to access the web interface. I do have the additional information below that I gathered from dietpi-services logs.

I'm a bit of a noob, but it looks like it might have to do with directory permissions. I do have my "dietpi-userdata" mounted on an external hard drive attached by USB.

Here is the log notes from attempting to restart the syncthing service today:

● syncthing.service - Syncthing (DietPi)
│ Loaded: loaded (/etc/systemd/system/syncthing.service; disabled; vendor preset:
│ enabled)
│ Active: failed (Result: exit-code) since Thu 2019-10-24 11:39:16 EDT; 15s ago
│ Process: 9382 ExecStart=/etc/syncthing/syncthing
│ -logfile=/var/log/syncthing/syncthing.log -logflags=3
│ -home=/mnt/dietpi_userdata/syncthing (code=exited, status=1/FAILURE)
│ Main PID: 9382 (code=exited, status=1/FAILURE)
│
│ Oct 24 11:39:14 Wolfberry syncthing[9382]: [monitor] 2019/10/24 11:39:14 INFO:
│ Starting syncthing
│ Oct 24 11:39:14 Wolfberry syncthing[9382]: [start] 2019/10/24 11:39:14 INFO:
│ syncthing v1.3.0 "Fermium Flea" (go1.13.1 linux-arm) [email protected]
│ 2019-10-01 05:34:58 UTC
│ Oct 24 11:39:14 Wolfberry syncthing[9382]: [start] 2019/10/24 11:39:14 INFO:
│ Generating ECDSA key and certificate for syncthing...
│ Oct 24 11:39:15 Wolfberry syncthing[9382]: [start] 2019/10/24 11:39:15 WARNING:
│ Failed to load/generate certificate: save cert: open
│ /mnt/dietpi_userdata/syncthing/cert.pem: permission denied
│ Oct 24 11:39:15 Wolfberry syncthing[9382]: [monitor] 2019/10/24 11:39:15 INFO:
│ Syncthing exited: exit status 1
│ Oct 24 11:39:16 Wolfberry syncthing[9382]: [monitor] 2019/10/24 11:39:16 INFO:
│ Default folder created and/or linked to new config
│ Oct 24 11:39:16 Wolfberry syncthing[9382]: [monitor] 2019/10/24 11:39:16 WARNING: 4
│ restarts in 9.011826s; not retrying further
│ Oct 24 11:39:16 Wolfberry systemd[1]: syncthing.service: Main process exited,
│ code=exited, status=1/FAILURE
│ Oct 24 11:39:16 Wolfberry systemd[1]: syncthing.service: Unit entered failed state.
│ Oct 24 11:39:16 Wolfberry systemd[1]: syncthing.service: Failed with result
│ 'exit-code'.

When I cd into the directory this is the permissions that I see for the directories that syncthing is creating and attempting to use when it starts up:

drwx------ 2 root root 4096 Oct 23 14:51 syncthing
drwxr-xr-x 2 root root 4096 Oct 23 14:51 syncthing_data
drwxrwxr-x 2 dietpi dietpi 4096 Jan 23 2019 Video

I included the "Video" directory, not because syncthing created it, but it was created in that same userdata directory and it has very different permissions from the two folders created by syncthing.

I also sent the following dietpi-bugreport:
Bug report sent, reference code: 9a39253a-499a-4358-ac3b-8bbeb55ee5c8

I hope this helps.

@g7kse
Copy link

g7kse commented Oct 24, 2019

Me three. Same install setup as @mowestusa

MichaIng added a commit that referenced this issue Oct 24, 2019
@MichaIng
v6.27
e370527 
+ DietPi-Software | Syncthing: Move binary from /etc/syncthing to /opt/syncthing
+ DietPi-Software | Syncthing: Align systemd unit with official one, which includes some hardening and signal handling that should allow internal updates without breaking service state. Hence leave internal updater enabled by default.
+ DietPi-Software | Syncthing: Do not touch config file on reinstalls. Otherwise create default config as user dietpi to assure correct permissions: #3180 The dir itself is created automatically with most strict access permissions (owner only).
+ DietPi-Software | Syncthing: The inotify-based FS watcher is now enabled by default, hence we can stay with defaults, as well the 1h rescan interval. As well leave browser start default enabled, disable instead via cmd option in systemd unit, where it is required. This allows user to access browser via binary from console.
@MichaIng MichaIng mentioned this issue Oct 24, 2019
Merged
2 tasks
@MichaIng
Copy link
Owner

MichaIng commented Oct 24, 2019 •
edited
Loading

@ralban @mowestusa @g7kse
Many thanks for your reports and debugging. Indeed we run the config dir creation command during install with wrong user (root instead of dietpi), which causes the issue in combination with: #3040

Fix is:

chown -R dietpi:dietpi /mnt/dietpi_userdata/syncthing
systemctl restart syncthing

I opened a PR to fix it and enhanced/updated the installer in some other ways for next release: #3202

  • Most important change: Internal auto updater stays enabled (needs some failsafe testing)
  • Minor security hardening, as provided by Syncthing on GitHub

@MichaIng MichaIng added this to the v6.27 milestone Oct 24, 2019
@MichaIng MichaIng changed the title SyncThing not available after install DietPi-Software | Syncthing: Service fails due to permission issue Oct 24, 2019
@MichaIng MichaIng pinned this issue Oct 24, 2019
@g7kse
Copy link

g7kse commented Oct 25, 2019

Ok Thanks @MichaIng all ok on gui which is now displayed but we still have a permission problem with folders

2019-10-25 08:24:18: Failed to create folder marker: mkdir /mnt/dietpi_userdata/syncthing_data/.stfolder: permission denied

2019-10-25 08:24:18: Error on folder "Syncthing Data" (0000-0000): folder marker missing

@MichaIng
Copy link
Owner

@g7kse
Ah that's true:

chown -R dietpi:dietpi /mnt/dietpi_userdata/syncthing*
systemctl restart syncthing

@g7kse
Copy link

g7kse commented Oct 25, 2019

All sorted. tnx

Alex

MichaIng added a commit that referenced this issue Oct 28, 2019
@MichaIng
v6.27 (#3202)
55e3583 
+ DietPi-Software | Syncthing: Move binary from /etc/syncthing to /opt/syncthing
+ DietPi-Software | Syncthing: Align systemd unit with official one, which includes some hardening and signal handling that should allow internal updates without breaking service state. Hence leave internal updater enabled by default.
+ DietPi-Software | Syncthing: Do not touch config file on reinstalls. Otherwise create default config as user dietpi to assure correct permissions: #3180 The dir itself is created automatically with most strict access permissions (owner only).
+ DietPi-Software | Syncthing: The inotify-based FS watcher is now enabled by default, hence we can stay with defaults, as well the 1h rescan interval. As well leave browser start default enabled, disable instead via cmd option in systemd unit, where it is required. This allows user to access browser via binary from console.
+ DietPi-Software | Syncthing: Remove file logging in favour of journal logging. Users should use journalctl (-u syncthing) to check logs
+ DietPi-Patch | Prepare and reinstall Syncthing to apply recent changes: #3202
@MichaIng MichaIng unpinned this issue Oct 28, 2019
@MichaIng MichaIng mentioned this issue Nov 13, 2019
Merged
@MichaIng MichaIng mentioned this issue Dec 8, 2019
Closed
@MichaIng MichaIng mentioned this issue Dec 30, 2019
Merged
@MichaIng MichaIng closed this as completed Jan 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug 🐞 Solution available 🥂 Definite solution has been done
Projects
None yet
Milestone
v6.27
Development

No branches or pull requests
4 participants
@g7kse @MichaIng @mowestusa @ralban