Installed v0.14.50, Linux (64 bit) on Ubuntu 16.04. Default setup works fine - both if running af user root or my own user.
But regardless of user, trying to add a new dedicated folder I get above error. As root following examples messages:
2018-09-20 11:15:53: Failed to create folder root directory mkdir /kv-home: read-only file system
2018-09-20 11:15:53: Error on folder “#sync” (dcxqv-x4njb): folder path missing
2018-09-20 11:18:03: Failed to create folder marker: mkdir /home/#sync/.stfolder: permission denied
2018-09-20 11:18:03: Error on folder “#sync” (nyenw-rgtpt): folder marker missing
In both cases I did create folders i advance… ‘kv-home’ is mounted to raid-6 disks running Ext4. ‘home’ is on raid-1 also Ext4
If subfolder does not exist - it is not created. If it exist it tries to create on root level and fails… Both as user root and my user. Of course the actual root level (parent folder) always DOES exist - so should actually not be tried to create at all…
First: Default setup IS working - both is running af ‘root’ - and if running as user ‘frank’.
Problem: default placement of shared folder in user structure and on space restricted system partition.
Following folders exist
\kv-home
\home
I try now to create a synced folder #sync in first one and then the other of these folders. It fails.
Then I create the ‘#sync’ folder manually first, having
\kv-home\#sync
but seems syncthing does not get this, and still fails.
To eliminate any rights issues, I’ve tried this both for user ‘root’ and ‘frank’. Same result ‘folder path missing’.
If i try to copy the .stfolder and edit config file, same result…
both ‘root’ and ‘frank’ can create folders inside mentioned folders, while only root can work on \ level… I think that is standard.
Not familiar with fsck - but system denies to run it…
For further testing - manually created
/home/#sync/.marker
Can actually share now, but get:
For the following folders an error occurred while starting to watch for changes. It will be retried every minute, so the errors might go away soon. If they persist, try to fix the underlying issue and ask for help if you can't.
#sync open /home/#sync/.marker: permission denied
Checked permissions… Exact same as in default share.
These errors are coming from the kernel, and not from the app. Check how the app is started, perhaps its running as a different user, or perhaps its running on some sort of NAS that has funky filesystem permissioning semantics.
Thx. Yes - verified to be some filesystem problem now… But how / why / what?
It’s server running Ubuntu 16.04. Disks are on Adaptec raid adapter - system disks raid1, data disks raid6.
All partitions running EXT4 filesystem. So - nothing exotic at all.
On systems disk I can setup /home/#sync and works fine with syncthing as long as I create folders and runs service as ‘root’.
On data disks same method, setup /kv-home/#sync - also as ‘root’ - but fails as shown…
The difference is the filesystem - but why would systempartition work, and not datapartition?
Data partitions created using gparted - and mounted…
If anyone can give a hint, I can try changing / deleting / creating partitions to tryout different settings… I’m only Ubuntu on user level - but CAN type a command in terminal…
If the folders are owned by root, but syncthing runs as a different user, then I’d say that failures are expected, and you should run syncthing as the user who owns the directories.
Who maintains this then…? Might be dumb question - but I really do not know.
I checked - and the permission setting shown in ‘ubuntu software’ (tool to install packages) is only shown for syncthing - so must be defined by syncthing package
No. We do not interact with the software center. This might be some kind of “security feature” of ubuntu that restricts disk access for programs not installed trough their repos.
Anyway, did enabling read/write access to removable storage on the ubuntu software center fix your issue?
Then I suggest asking in the appropriate support venue of ubuntu software center about that - I and I guess many others here as well have no clue about that.
Lots of testing done. Did manage to get the ‘removable storage’ setiing to ‘On’, but did not solve problem…
As workaround I setup a new mapping for /home to a dedicated storage partition, and that works. Strange as using another folder on same partition does not work…
So - using /home sorts of overrides other restrictions.
Really strange. Also found the an sata drive mounted in a hardware ejectable bay also work, as this by ubuntu is seen as internal disk !?!?!?
So boils down to being Ubuntu handling og raid drives causing the problem somehow.
…after getting the workaround in place the next challenge was to get it all running as service…
Finding no usable guides - or rather - all available guides points to folders which in my install contained nothing - i found out that i by ‘accident’ had installed syncthing from snapcraft store.
So -I uninstalled that packeage, and reverted to ‘manual’ install instead.
Now - all docs are spot on - and quickly got the service running.
Just for the fun of it, i tried to use data partition on raid drives - and it works!!!
So - all my troubles was basically caused by the snap install doing stuff differently. Also this permission setting seems native to snap (?)
Conclusion: do NOT use snap / store until properly tested and documented.
I admit, being ubuntu user with limited knowledge, i’m often used to blindly following setup guides - so i easily get lost in case of problems. Several days of digging / testing this time at least revealed the REAL problem.
anyway, syncthing is now running as hoped, so thx for great product
