Long-winded first posting, I have tried to be succint while providing details.

I am working on an AIX 6.1 server where SFTP (via WinSCP) is already used by several service accounts to access files in many subdirectories of /app/data.

I've been asked to set up an SFTP user account to allow access to two of the subdirectories, /app/data/bills & /app/data/invoices, but it must not be able to access the other subdirectories or anywhere else on the server. I am not allowed to change any owner, group or permissions within the /app directory branch.

Following this link - Configure an sftp chroot environment - I have successfully created an account with home directory of /sftpjail/sftpuser and have confirmed a) it cannot log on via other methods (SSH, console) and b) it can connect via WinSCP and can only see the contents of its home directory.

  • My /etc/ssh/sshd_config section is as follows:
Match Group sftpgrp
        ChrootDirectory %h
        ForceCommand internal-sftp
        AllowTcpForwarding no
        PermitTunnel no
        X11Forwarding no
  • The directories and files under the /app/data branch are all owned by appsuser and in the group appsgroup and the permissions are 775 (ug=rwx,o=rx).

  • The sftpuser account is also a member of the appsgroup group.

I have created symbolic links to /app/data/bills in the user's home directory, I presume this doesn't work because the link is a path to a directory outside of the chroot.

I have tried mounting the /app/data/bills directory onto a mountpoint within the users's home:

cd /sftpjail/sftpuser
mkdir bills
mount /app/data/bills bills

... this latter approach had some interesting results:

  • I could connect via WinSCP and see the bills directory, if I double-clicked it then I would be given an error dialogue and, when cleared, I would be "in" the directory but unable to see any content.

  • If I used sftp sftpuser@localhost from the AIX server, it would let me navigate into the bills directory without a problem but an ls of the content would give the remote readdir("/bills"): Failure message.
    I was able to further navigate into the /bills/2019 and /bills/2019/09 subdirectories, each time an ls produced the same error.
    However, it gets really interesting when I put a temporary file into /bills, not only did it successfully upload the file but after doing so it would allow ls to work. As soon as I deleted the temporary file it want back to erroring, put the file back and ls works again.

Question 1: Should it be possible to access directories that are outside of a chroot home and, if so, how?

Question 2: Is there another way to achieve the required result? One that does not involve installing third-party software.

I appreciate your patience if you have read this far.


Symlinks are essentially just pointers to another file, but you can't point to something outside the chroot because it would be looking for a file with that name which doesn't exist inside the chroot.

You could use mount with bind to remount the directories you need in the jail.

For example:

# mount --bind /bin /chroot/bin
# mount --bind /lib /chroot/lib
# chroot /chroot

If you wish to place it in /etc/fstab, the same example would look like:

/bin /chroot/bin none bind
/lib /chroot/lib none bind
  • Hi harrymc, unfortunately AIX mount command does not seem to support the 'bind' option. However, I thought I had found a work-around in that it is possible to do a 'namefs' type of mount, which allows you to mount an existing directory at another location: crfs -v namefs -A yes -d /app/data/bills -m /sftpjail/sftpuser/bills – Nick Clifton Oct 14 at 12:07

As mentioned in the comment to @harrymc, I thought I had found the answer with the 'namefs' mount type, however even though it allowed the SFTP session to navigate to the mountpoint, the 'ls' command showed it as empty (it wasn't).

My team lead, a very smart chap, suggested it might need a dot file in the source directory to allow browsing, so I created a '.do-not-delete' file and, Hey Presto!, it worked. But (you knew this was coming, I bet) ... it needed a dot file in EVERY subdirectory that the user needed to browse, not really sustainable if there are regular new subdirectories created.

Further testing revealed that the presence of the dot file had mixed and unpredictable results, for example, while in an SFTP session, I deleted a temporary file and then found I could no longer browse the directory. When I deleted the dot file, from a separate SSH session, the ability to browse came back. I eventually found just about every combination of presence or lack of dot file and abililty or not to browse.

At this point it was decided that due to the unpredictable behaviour, combined with the age of the OS and the SFTP package, and the lack of any viable upgrade path, this was not a viable solution and the team requesting this access needed to go back to the drawing board.

Thanks to harrymc for the 'bind' suggestion and to anyone and everyone who took the time to read this.



P.S. I am happy for this to be closed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.