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.

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

path exists, but folder marker missing, check for mount issues #891

Closed
MrClayPole opened this Issue Oct 21, 2014 · 21 comments

Comments

Projects
None yet
9 participants
@MrClayPole
Copy link

MrClayPole commented Oct 21, 2014

I have 4 folders shared from my file system that are not nested. 3 of the are on a read only file system and I get the errors below.

13:56:06 WARNING: Stopping folder "Share1" - path exists, but folder marker missing, check for mount issues
13:56:06 WARNING: Stopping folder "Share2" - path exists, but folder marker missing, check for mount issues
[4XMC7] 13:56:06 WARNING: Stopping folder "Share3" - path exists, but folder marker missing, check for mount issues

The 4th is read write and there are no issues sharing the folder. All 4 shares worked with this configuration up to version v0.10.1 but as soon as I updated to v0.10.2 I get the errors above.

@AudriusButkevicius

This comment has been minimized.

Copy link
Member

AudriusButkevicius commented Oct 21, 2014

When you started the new version of syncthing it tried to create folder markers (empty .stfolder file in the root), since your filesystem is read only it failed to do so.
We now use this file to validate if the filesystem has been mounted properly (to guard ourselves against #762)

Just out of curiosity, how is syncthing supposed to sync into a readonly file system?

@calmh

This comment has been minimized.

Copy link
Member

calmh commented Oct 21, 2014

In this case, create the .stfolder empty file on those shares to indicate that they are in fact shares and you should be good to go.

@ShawnMilo

This comment has been minimized.

Copy link

ShawnMilo commented Oct 22, 2014

I had the same problem on one of my machines, and nothing was read-only. I added the file (touch .stfolder) and that seems to fix it. Another machine, identically configured as far as I know (my home and work machines -- sharing all the same folders) had the files added automatically.

@ShawnMilo

This comment has been minimized.

Copy link

ShawnMilo commented Oct 22, 2014

Update: I added all the files and the ugly red went away. It all synced nicely. And all the .stfolder files I created have disappeared. Upon restarting syncthing, everything's ugly and red again and I'm getting "path exists, but folder marker missing, check for mount issues" on all my folders again.

@alex73

This comment has been minimized.

Copy link

alex73 commented Oct 23, 2014

Just out of curiosity, how is syncthing supposed to sync into a readonly file system?

It's very usable for share some important information that changed occasionally and manually. I don't want to some software on my computer will be able to change these files. Main node contains read-only folder but child nodes contains usual read/write folders.

@ShawnMilo

This comment has been minimized.

Copy link

ShawnMilo commented Oct 23, 2014

Another update: Every time I add the .stfolder files to my directories, everything is fine. Then all the .stfolder files magically disappear shortly after all the scanning and syncing completes. SyncThing continues to perform normally until it's restarted, at which point it gets all red again.

If I re-add the files while it's running and wait, it will delete them again after a while. So, whether I add the files with SyncThing running or stopped, it still deletes them.

I've checked these files against the .stfolder files on the machine I'm syncing to, and they have the same file permissions and size (zero bytes).

I don't know if it makes a difference, but the other machine's "bar" never turns from blue to green. It reaches 100%, but then stays blue. It says "Syncing (100%)" forever.

I've deleted the entire ~/.config/syncthing/index directory (with SyncThing off), then turned it back on and let it rebuild. This did not fix the problem. I tried it twice.

And this is NOT with a read-only filesystem, nor am I out of drive space.

@calmh

This comment has been minimized.

Copy link
Member

calmh commented Oct 23, 2014

That seems distinctly weird, syncthing shouldn't see those files apart as folder markers, and should certainly not delete them... Are you sure it's not something else that deletes them?

@getabc

This comment has been minimized.

Copy link

getabc commented Oct 23, 2014

same problem here since v0.10.2 upgrade on both our Linux and Windows master servers. Folders that had 'ignore patterns' are now reporting 'folder marker missing', but folders originally configured without 'ignore patterns are working fine.

Yikes!

@ShawnMilo

This comment has been minimized.

Copy link

ShawnMilo commented Oct 23, 2014

@calmh I did a lot of troubleshooting and the issue wasn't with syncthing. It was an unexpected side-effect of a cron task on my one machine. Sorry it took so long to reply -- it took a lot of testing to narrow down. My bad.

@calmh

This comment has been minimized.

Copy link
Member

calmh commented Oct 24, 2014

@getabc Can you reproduce that with a config that you can share? I have ignore patterns and do not see this.

@AudriusButkevicius

This comment has been minimized.

Copy link
Member

AudriusButkevicius commented Oct 28, 2014

Closing this, reopen if its still an issue.

@RafiKueng

This comment has been minimized.

Copy link

RafiKueng commented Dec 19, 2014

I still have this problem: (v0.10.13)

I'm running syncthing (local install in ~/.local/bin/; running in a 'screen' session) on an university machine as a user (OpenSUSE 13.1) where I don't have root access. Some random folders don't seem to work, with the same error message: "path exists, but..."

Some are on a nfs mount (my home directory mounted on /home/[group/[user]/), but others are on the local harddrive (/dev/sda8 -> /data). I have write access to all of them (I'm the owner of these folders, I can manually create files within using dolphin or 'touch'ing files)

Creating a .stfolder file sometime worked, but then upon sync, the other nodes deleted all the files in the particular folder. After try and error, mostly with newly created folders, and a few backup restores, I could get 3 of 4 folders to sync. The one on the local drive still don't seem to work... It's kinda strange behavior, I didn't find any pattern Have you any advice how to track the possible bug down? I'd be glad to help.

The default folder "~/Documents" in the home directory was particular resilient to being accepted.. But other folders I created manually as well.. Those folders that eventually got accepted (all subfolders under ~) are running well so far.

And maybe one word of advice: MAKE BACKUPS: I had data loss when playing around with creating .stfolder files manually (no harm done to me thanks for backups ;))

@ShawnMilo

This comment has been minimized.

Copy link

ShawnMilo commented Dec 19, 2014

Check for anything which could possibly be deleting zero-byte files. Fun idea -- next time you have to re-add a file, try putting a letter or something in it. See if it still gets deleted. In my case, I had a script that tried to cd into another folder and delete zero-byte files. The folder it tried to cd to went away, so it ran the deletes in my home folder. Duh.

@RafiKueng

This comment has been minimized.

Copy link

RafiKueng commented Dec 19, 2014

I'm having the situation right now, so I can check all your advice..
Creating a zero byte file within the affected folder has no unexpected effect.

/data/files> touch .stfolder
/data/files> ls -a
. .. .stfolder

Btw: Does it try only once to create the .stfolder file or will it try every time the process gets restarted?

@ShawnMilo

This comment has been minimized.

Copy link

ShawnMilo commented Dec 19, 2014

I don't know the circumstances under which syncthing will try to create it.

You might also write a script that checks for the file and run it in cron every minute, having it output the timestamp and result in a log. That way, you can find out when it goes missing. If you see a pattern in what times it goes away that could help you figure out the problem.

Something like this:

if [ ! -f "/home/username/shared/.stfolder" ]; then echo "File missing! $(date)"; fi

@RafiKueng

This comment has been minimized.

Copy link

RafiKueng commented Dec 19, 2014

hmm I guess I was looking for the error at the wrong place.. The file never got created in the first place as far as I can tell.
Some other strange things happened:
Changes made to the config in the gui didn't got accepted (didn't show up in the config file), and restarts (from gui) didn't had any effect (service didn't got restarted, but kept on running). So somehow the interface service -> webgui was broken. (the other direction worked thou)
I did backup my certs and deleted the config folder (~/.config/syncthing) and started from scratch, that helped.

Now the question is, why did the other configuration lock up.. I'll try to investigate, but that's not related to this bug. Sorry for the traffic!

@AudriusButkevicius

This comment has been minimized.

Copy link
Member

AudriusButkevicius commented Dec 19, 2014

The cookies used for auth are held in memory so upon restart thr session IDs are lost. If your browser chose not to provide basic auth, and the session ID is invalid, you get read only access of the UI.

As to your issues with stuff difappearing, I think it will be syncthing starting before mounts are setup. That is the reason .stfolder is there to start eith, but it seems something goes wrong.

@JujuLand

This comment has been minimized.

Copy link

JujuLand commented Jun 15, 2016

Hi,

I have similar problem :

2016-06-15 16:15:43: Stopping folder "cv2d3-pzjRv" - folder marker missing

I hay two computers, ordi1 with user1 and ordi2 with user2 and user3
user1 share folder1 with user2 and user3

When I put it in place, I first work with user1
Then I work with user2, and synchronize between user1 and user2 => ok (now user1 has folder1 and folder2
I disconnect user2, and connect user3
I work with user3 and synchronize between user1 and user3 => it beguns, but stop at 94%, and I have this message.
The message appears about a subfolder originally in folder2 of user2

Obviously, .stfolder exists in folder1 of user1

If you have an idea about my problem.

Thanks
A+

@ShawnMilo

This comment has been minimized.

Copy link

ShawnMilo commented Jun 15, 2016

@JujuLand Do you have any scripts that automatically delete zero-byte files on one of your machines? That's what happened to me.

Also, as I mentioned above you could write a script that logs whether it sees the file and run it in a loop (or every minute), then see if you can use the knowledge of when in disappeared to backtrack to what event actually causes it.

@canton7

This comment has been minimized.

Copy link
Member

canton7 commented Jun 15, 2016

Please don't comment on ancient issues: open a new issue, or post on the forum for user support queries (as this appears to be)

I'm going to lock this issue now, so please copy your message into a new forum thread.

@syncthing syncthing locked and limited conversation to collaborators Jun 15, 2016

@AudriusButkevicius

This comment has been minimized.

Copy link
Member

AudriusButkevicius commented Jun 15, 2016

Or to be honest, use the forums.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.