Does SeaDrive work with an SFTP server restricting users to an SFTP root jail and with no ssh login?

SeaDrive
1

Users will place files in libraries synced with my server. As a file arrives at the server it may get removed by my application (compiled C++). The server may process the file and place the resulting file into another synced directory so that the remote user may have it. SeaDrive will need to alert my application of the arrival of new files and allow it to move them. Also SeaDrive needs to allow the application to place files in synced libraries.

The server is an SFTP server on Linux restricting users to an SFTP root jail and with no ssh login. Server controls the tree structure of synced libraries and remote users must not do any sharing. Users can be on Linux or Windows.

2

I haven’t really tried this, but I think it could work. SeaDrive does use a fuse mount, so the SeaDrive program would have to run as the same user as the sftp server for the server to be able to see into the SeaDrive directories.

I don’t know of an API in seafile that could notify your program that a new file has been created, so if someone else does, I would encourage them to respond. You might be able to use inotify to have the OS tell your program that a file has been added. But my experience several years ago with inotify and fuse mounts wasn’t great.

Instead I would suggest a cron job to check once every 5 minutes (or 1 minute or whatever) for new files files in the “inbox” directory. That’s a pattern I’ve used a few times and it’s pretty easy to work with (easy to troubleshoot to get it working, and seems to pretty reliably stay working).

Again because of the fuse mount your program would also need to run as the same user that runs the SeaDrive client for it to have access to pull files out of the inbox and write completed work to the outbox directory.

As an alternative, you might try the seafile client instead of SeaDrive. This has the advantage of not needing the fuse mount, so the client doesn’t need to run as the same user as the sftp server. This could make inotify work better if you really want to use it. The only disadvantage I can think of is that seafile expects to sync the entire library, so this application server needs enough disk space for all the files in the library, where SeaDrive might only need a few GBs for the most recently accessed bits.

If you do use seafile both seafile and sftp will need sufficient access to the files, so you might need to make sure both users are in a group together, and maybe set the sticky permission on the sync directories, but that’s not too hard to deal with.

3 
I haven’t really tried this, but I think it could work. SeaDrive does use a fuse mount, so the SeaDrive program .

winfsp is FUSE ported for windows. How might SeaDrive be configured for winfsp or an alternative?

would have to run as the same user as the sftp server for the server to be able to see into the SeaDrive directories

The library tree is controlled by the server and the remote user can only shuv files in and out, and is not allowed to do any sharing. Users access trees belonging to the server admin. I take it this is possible.

I don’t know of an API in seafile that could notify your program that a new file has been created, so if someone else does, I would encourage them to respond. You might be able to use inotify to have the OS tell your program that a file has been added. But my experience several years ago with inotify and fuse mounts wasn’t great.

I have used inotify; will SeaDrive be tolerant to it. Will SeaDrive allow a compiled C++ application in the back end direct access to the libraries or will it be required to go through SeaDrive? If so, is there an API or functions the C++ must use?

Instead I would suggest a cron job to check once every 5 minutes (or 1 minute or whatever) for new files files in the “inbox” directory. That’s a pattern I’ve used a few times and it’s pretty easy to work with (easy to troubleshoot to get it working, and seems to pretty reliably stay working).

I will consider cron of inotify faces problems.

Again because of the fuse mount your program would also need to run as the same user that runs the SeaDrive client for it to have access to pull files out of the inbox and write completed work to the outbox directory.

It is the compiled C++ on the server back end behind SeaFile that is providing service by processing files for the remote users and putting the resulting files in download libraries where the remote user expects them. The remote user is not the one providing a service in this application.

As an alternative, you might try the seafile client instead of SeaDrive. This has the advantage of not needing the fuse mount, so the client doesn’t need to run as the same user as the sftp server. This could make inotify work better if you really want to use it. The only disadvantage I can think of is that seafile expects to sync the entire library, so this application server needs enough disk space for all the files in the library, where SeaDrive might only need a few GBs for the most recently accessed bits.

In this application, the server is not used as a storage space; files are uploaded (one or a few at a time) through an upload library, taken away and processed by the C++ and resulting files are placed in a download library. Not really concerned about Gigs of space or syncing overhead. I am not an IT person. I am in Semiconductor Design and Verification needing a ready made solution for this. I may place the application as open source later. For now I need a prototype with some functionality to get other people interested to contribute.
If there is no network drive, how will remote users work? Where will the files needing processing be placed to get uploaded to the server? Is it command line? Users are not computer savvy and may not be interested in computers.

If you do use seafile both seafile and sftp will need sufficient access to the files, so you might need to make sure both users are in a group together, and maybe set the sticky permission on the sync directories, but that’s not too hard to deal with.

Regarding access, the server admin has control over the libraries and not the user. The admin can create a tree and a corresponding user group of one person plus the admin. In my mind that should solve the access problem. The remote user is not allowed to do any sharing; he cannot create libraries. I hope that is possible or I may not be able to use Sea/File/Drive.
I have yet find out what the sticky bit does/is. Will transfer in both directions be in sftp?
By the way, for security purposes, currently each remote user has his own sftp root jail and no ssh login. I can do away with those if Sea/Drive/File has sufficient security.

4

Sorry, I know nothing about windows internals, so can’t help with winsfp. Maybe someone else knows the answer?

As for the API questions what I was trying to say is that (again on Linux since I don’t use windows and know nothing about it) you would interact with it by listing files, creating files, read and writing files, and deleting files. All that through the normal OS mechanisms so no special extra API would be needed. Since SeaDrive runs as a filesystem any program can work with it on those terms.

I don’t think I would use the seafile client for this use on windows. Windows has unique ideas about how file access should work. On windows you can get sync errors if seafile tries to read from a file before your program has finished writing to it (or for some reason still has the file open). This behavior of only allowing one program to use a file at a time also caused us to see sync errors when backups were running, and even sometimes when Word crashed with a file open (somehow locking it open until the next reboot). Maybe you know some way around that problem (I will admit, my team didn’t even try since we weren’t paid to support the windows users), but if not it might be best to avoid those problems by sticking to seadrive.

In Linux by default (I think this is configurable) fuse filesystems mounted by a normal user are only accessible to that user, regardless of file permissions. This is why I was saying you would need to have your program and SeaDrive run with the same user id. Again no idea if or how that applies to windows.

And to clear up what I was saying about accessing the files, I meant permissions on at the filesystem level. AFAIK seafile doesn’t preserve any file permissions or ACLs or even ownership metadata. When a file is sent to the server it becomes a file owned by the owner of the library (by virtue of being in the library). And the opposite is true. If the client is logged in as user A, and B shared a file to A, the client program will sync it to the local system where it is then created and owned (from the point of view of the local FS) by the user who is running the client. If it was read-only on A’s machine it won’t be when it gets to B’s.