file sharing in the 21st century
-
@Donahue said in file sharing in the 21st century:
@JaredBusch said in file sharing in the 21st century:
@wrx7m said in file sharing in the 21st century:
@JaredBusch Interesting.
The fact that it works for you without even trying means that you have some kind of Nat hairpin already in place whether you know it or not
Blame fortigate
-
@JaredBusch said in file sharing in the 21st century:
@Donahue said in file sharing in the 21st century:
@JaredBusch said in file sharing in the 21st century:
@wrx7m said in file sharing in the 21st century:
@JaredBusch Interesting.
The fact that it works for you without even trying means that you have some kind of Nat hairpin already in place whether you know it or not
Blame fortigate
He may not know it by that "Hairpin NAT" term. When I first heard it a couple years ago or whenever, I had no idea idea it meant "NAT loopback", which is the only tearm I've heard or seen it called before that.
-
@Obsolesce said in file sharing in the 21st century:
@JaredBusch said in file sharing in the 21st century:
@Donahue said in file sharing in the 21st century:
@JaredBusch said in file sharing in the 21st century:
@wrx7m said in file sharing in the 21st century:
@JaredBusch Interesting.
The fact that it works for you without even trying means that you have some kind of Nat hairpin already in place whether you know it or not
Blame fortigate
He may not know it by that "Hairpin NAT" term. When I first heard it a couple years ago or whenever, I had no idea idea it meant "NAT loopback", which is the only tearm I've heard or seen it called before that.
I remember last year a discussion like that with @JaredBusch since Sonicwall and other firewalls refers them as NAT Loopback.
-
@Obsolesce said in file sharing in the 21st century:
I had no idea idea it meant "NAT loopback", which is the only tearm I've heard or seen it called before that.
Interesting, I had only heard the term hairpin for years, until I taught myself more about the networking side of things.
-
@JaredBusch said in file sharing in the 21st century:
@Obsolesce said in file sharing in the 21st century:
I had no idea idea it meant "NAT loopback", which is the only tearm I've heard or seen it called before that.
Interesting, I had only heard the term hairpin for years, until I taught myself more about the networking side of things.
Same here, hairpin is the only one I've traditionally heard.
-
To refresh the memory this is the discussion I was talking about @Obsolesce
https://mangolassi.it/topic/16233/website-internal-external -
@Obsolesce said in file sharing in the 21st century:
@JaredBusch said in file sharing in the 21st century:
@Donahue said in file sharing in the 21st century:
@JaredBusch said in file sharing in the 21st century:
@wrx7m said in file sharing in the 21st century:
@JaredBusch Interesting.
The fact that it works for you without even trying means that you have some kind of Nat hairpin already in place whether you know it or not
Blame fortigate
He may not know it by that "Hairpin NAT" term. When I first heard it a couple years ago or whenever, I had no idea idea it meant "NAT loopback", which is the only tearm I've heard or seen it called before that.
Yup. I had heard the term, didn't know it was synonymous with NAT loopback.
-
@wrx7m said in file sharing in the 21st century:
@Obsolesce said in file sharing in the 21st century:
@JaredBusch said in file sharing in the 21st century:
@Donahue said in file sharing in the 21st century:
@JaredBusch said in file sharing in the 21st century:
@wrx7m said in file sharing in the 21st century:
@JaredBusch Interesting.
The fact that it works for you without even trying means that you have some kind of Nat hairpin already in place whether you know it or not
Blame fortigate
He may not know it by that "Hairpin NAT" term. When I first heard it a couple years ago or whenever, I had no idea idea it meant "NAT loopback", which is the only tearm I've heard or seen it called before that.
Yup. I had heard the term, didn't know it was synonymous with NAT loopback.
NAT Reflection when using pfSense.
-
Here's an update of my work and testing. I have NC up and most things are working as I expect, but I fear that I will run into similar issues to other people with the sync client. Most of my concerns related to using NC to host CAD files, or other non office files.
Based on my testing I have observed:
- There is no good file lock system with sync (and from what I read, webdav). I have the W2G2 app, and that can lock the web UI, but it sadly does not affect any other interfaces. I have read up on how NC handles conflicts and deliberately created some to verify the process. It was confusing at first, but then I realized that NC is only aware of uploads, not someone opening a file, particularly with the sync client. I forsee confusion on the part of my users, because they are all used to having a file lock when it is opened. If two people have the same file open, the first person to save gets to update the server and the second person gets the conflict, even if they opened it first. This would not happen to us everyday, but it would happen occasionally.
- The conflict files take awhile to appear. I am worried that the user that created the conflict (by the nature of saving second) will have moved on and will be no longer looking in that directory and it will be very easy to miss that there is a conflict. I would prefer if conflicts were uploaded to the server or even synced to other clients to increase the chance of seeing it before it became a big problem.
- NC either cannot say (or I don't have the right config) who created each version of a file, so when a conflict arises, and the user checks the web, they can see that there might be multiple versions, but no other useful information like what the change is, or who to ask. This might be very frustrating when the differences between two files is subtle.
- There doesn't appear to be any log that tracks all activities by all users. I seem to only be able to see activities that are related to the user in question in some way.
- OCR doesn't seem to work, but I would bet that is a config issues. Full text search does work though.
- When creating a share by email, there is no option to enforce a expiration date.
- We have two different versions of the windows sync client, 2.5.0 and 2.5.1, both say they are the most current and there are no updates. I have tried both on a second computer, and both versions will not show the sync icons, they just look like regular folders. The icons work fine on my end.
- Automated tagging is limited. I wish there was a setting where files would/could inherit tags from their parent folders.
None of these are deal breakers, but there are some definite holes that we would need to fix in our workflows. Some of these issue may be able to be overcome with better communication, but it made harder by the fact that in many cases, the user wouldn't know who to coordinate with.
I can conceive of overly complicated ways of making a hybrid of NC and NAS/File server. Something like using NC to sync two file servers together, and for remote access, while letting the users connect directly to the file servers to handle the locks. But part of me shudders and trying to keep a house of cards like that working.
-
@Donahue said in file sharing in the 21st century:
It was confusing at first, but then I realized that NC is only aware of uploads, not someone opening a file, particularly with the sync client.
Remember that the file is local, it would be impossible for NC to override the local file system. Given that it is a sync, no sync system can really do this. If it did this, it would be unable to work offline which is really its purpose. Locking on remote file systems is a universal problem that cannot have a simple solution. All systems, including SMB shares, share this problem.
-
@Donahue said in file sharing in the 21st century:
- The conflict files take awhile to appear. I am worried that the user that created the conflict (by the nature of saving second) will have moved on and will be no longer looking in that directory and it will be very easy to miss that there is a conflict. I would prefer if conflicts were uploaded to the server or even synced to other clients to increase the chance of seeing it before it became a big problem.
Again, this is universal and not related to NC. Same would happen with offline SMB.
-
@Donahue said in file sharing in the 21st century:
- There doesn't appear to be any log that tracks all activities by all users. I seem to only be able to see activities that are related to the user in question in some way.
have you installed the "Activity" app? Or "Activities for shared file downloads?" Or "Audit / Logging"? We use all of those and have decent visibility.
-
@Donahue said in file sharing in the 21st century:
- We have two different versions of the windows sync client, 2.5.0 and 2.5.1, both say they are the most current and there are no updates. I have tried both on a second computer, and both versions will not show the sync icons, they just look like regular folders. The icons work fine on my end.
What mechanism are you using for installing them?
-
I am aware of that. It's online locking that I am after. Though, I will concede that any locking scheme has to plan for both online and offline. I like sync because of local performance and offline availability, but it really feels like it is best for non shared files. When you add multiple users into the mix, almost everything goes out the window, especially when and if they go offline.
-
@scottalanmiller said in file sharing in the 21st century:
@Donahue said in file sharing in the 21st century:
- There doesn't appear to be any log that tracks all activities by all users. I seem to only be able to see activities that are related to the user in question in some way.
have you installed the "Activity" app? Or "Activities for shared file downloads?" Or "Audit / Logging"? We use all of those and have decent visibility.
AFAIK, those are all enabled and working correctly, they just dont show much. But I will check again.
-
@Donahue said in file sharing in the 21st century:
I am aware of that. It's online locking that I am after. Though, I will concede that any locking scheme has to plan for both online and offline. I like sync because of local performance and offline availability, but it really feels like it is best for non shared files. When you add multiple users into the mix, almost everything goes out the window, especially when and if they go offline.
Everything is best for non-shared files
SMB shines at "always online, always nearly local" files because it handles offline so poorly. It's a balance. To handle offline or very distant (e.g. high latency) networks well, you have to sacrifice locking.
-
@scottalanmiller said in file sharing in the 21st century:
@Donahue said in file sharing in the 21st century:
- We have two different versions of the windows sync client, 2.5.0 and 2.5.1, both say they are the most current and there are no updates. I have tried both on a second computer, and both versions will not show the sync icons, they just look like regular folders. The icons work fine on my end.
What mechanism are you using for installing them?
I am just using the same windows installer exe, at least in the case of the 2.5.0 which is what I have where the icons work. The 2.5.1 came from the download link inside the NC web UI
-
@scottalanmiller said in file sharing in the 21st century:
@Donahue said in file sharing in the 21st century:
I am aware of that. It's online locking that I am after. Though, I will concede that any locking scheme has to plan for both online and offline. I like sync because of local performance and offline availability, but it really feels like it is best for non shared files. When you add multiple users into the mix, almost everything goes out the window, especially when and if they go offline.
Everything is best for non-shared files
SMB shines at "always online, always nearly local" files because it handles offline so poorly. It's a balance. To handle offline or very distant (e.g. high latency) networks well, you have to sacrifice locking.
I understand that, but it also means that my users will be forced to deal with a limitation that is a sacrifice for a feature they don't usually use.
-
@Donahue said in file sharing in the 21st century:
@scottalanmiller said in file sharing in the 21st century:
@Donahue said in file sharing in the 21st century:
I am aware of that. It's online locking that I am after. Though, I will concede that any locking scheme has to plan for both online and offline. I like sync because of local performance and offline availability, but it really feels like it is best for non shared files. When you add multiple users into the mix, almost everything goes out the window, especially when and if they go offline.
Everything is best for non-shared files
SMB shines at "always online, always nearly local" files because it handles offline so poorly. It's a balance. To handle offline or very distant (e.g. high latency) networks well, you have to sacrifice locking.
I understand that, but it also means that my users will be forced to deal with a limitation that is a sacrifice for a feature they don't usually use.
Except it also gives them a huge performance leap, which in theory they use every time they touch a file.
-
@scottalanmiller said in file sharing in the 21st century:
@Donahue said in file sharing in the 21st century:
@scottalanmiller said in file sharing in the 21st century:
@Donahue said in file sharing in the 21st century:
I am aware of that. It's online locking that I am after. Though, I will concede that any locking scheme has to plan for both online and offline. I like sync because of local performance and offline availability, but it really feels like it is best for non shared files. When you add multiple users into the mix, almost everything goes out the window, especially when and if they go offline.
Everything is best for non-shared files
SMB shines at "always online, always nearly local" files because it handles offline so poorly. It's a balance. To handle offline or very distant (e.g. high latency) networks well, you have to sacrifice locking.
I understand that, but it also means that my users will be forced to deal with a limitation that is a sacrifice for a feature they don't usually use.
Except it also gives them a huge performance leap, which in theory they use every time they touch a file.
But with great power comes great responsibility. The conflict mechanism will surely catch them off guard for probably a long time, because it is too subtle.
