Ubuntu Server Perms Issue

I have migrated from using FreeNAS and jails to using ESXi and VM’s to manage my workflow. So far I am loving the freedom this has provided, but I am by all accounts a huge noob with literally everything I am doing here.

That said, I have most of what I need working, but I am having an issue with permissions.

I have my Ubuntu Syncthing VM set up to SMB to my FreeNAS data which works without issue. I can CD around the directories and syncthing was able to scan the files. But I am getting this error:

2018-09-14 12:32:21: Saving .stignore: open /mnt/syncthing/lightroom_sync/.syncthing.tmp.635362241: permission denied

So, I went to poke around my Ubuntu /mnt/syncthing dir, ls -la shows the dir is owned by root:root and is set to 751 I believe (drwxr-xr-x). Now I tried to chown -r this to 777 as I am the only person who uses this server so access control is not 100% critical (I would like to do things “right”, but this being a home kit and me being a noob, sometimes I just want things to work). Well, chown didn’t seem to do anything, I assume that is because its an SMB mounted dir? I am not sure.

In Ubuntu, I did add the group that owns the files on freenas to my user account, and I believe syncthing is running under my user account according to “ps -aux | grep -i syncthing” so I am not exactly sure what is wrong.

I have not tried to chown -R the dir on freenas itself. On FreeNAS, the dirs show as 770, but like I said, I am SMB’ed in with the user who owns the directories, and my ubuntu user is part of the group that owns the freenas dir’s.

Any help would be amazing!

You should make sure you can create the files or dirs that are specified in the error mesaage.

Yeah, this boils down to a FreeNAS question, which we’re not equipped to answer. Make sure the user you run Syncthing as can create files on your shares, and things should be happy.

I guess I should have asked a slightly different question.

It is true that the process will run as my user name, correct? The perms issue is not a syncthing issue, but I kinda figured I wasn’t the first person to have tried to use syncthing via SMB on Ubuntu server and maybe there where some pointers or advice for something I am missing.

I agree, I failed to actually check if I can write to the mounted volume which was a huge oversight lol. I will be back at my computer Monday and will obviously try that, but I very much assume I have no write permissions. I guess ultimately this is a Ubuntu question, or more specifically maybe a SMB question. Just hoped someone on here would have had experience with it.

Also, performance wise it is probably not ideal to point syncthing to an smb mount. It probably works, but as far as I understand you do have control over the device, where the samba mount is shared from. Ideally you would run syncthing there and point it to the actual data on disk.

1 Like

I suppose I could continue to run syncthing in a FreeNAS jail, I was just never a fan of Jails to begin with.

As far as performance, I think theoretically it shouldn’t be much different. If I understand the VMXNET3 virtual lan adapter, it can run as fast as the kernel allows memory to be accessed. That said, the Ubuntu side is still going through the SMB protocol.

I guess I am curious why SMB would be so much less preferred? One of the reasons I wanted to switch to Ubuntu was the ability to have more control over the creation of files. I have yet to successfully have my FreeNAS jail follow a umask, I figured it would be easier under Ubuntu. But that was really the only major change I anticipated.

I was talking about the SMB part, no idea about all the rest. I don’t know how much of an impact it is, but every time syncthing stat’s a file, that needs to go through smb and then the actual filesystem - it just means there is an additional layer in between. That might be perfectly fine without relevant performance impact, but if in your setup it was possible (and it might well not be or too complicated), to run syncthing directly without the smb layer in between, that would exclude any problems with that extra layer. That’s all I am getting at.

That’s true. Thinking about it more, it’s probably the correct approach.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.