sub-directories initially only accessible by root

[oshunluvr]

sub-directories initially only accessible by root

Client: (K)Ubuntu 16.04 LTS - new install (not upgrade) fully up-to-date
Server: Ubuntu 14.04 LTS - fully up-to-date
Client Package: nfs-common 1:1.2.8-9ubuntu12

No access issues using Kubuntu 15.04 client in the past or currently. Server configuration unchanged.

Attempting to access all subfolders of NFS mount fails for user. Primary folder is listable, subfolders are not, files in first level folder are accessable. If a subfolder is accessed by root user, it (and all nested subfolders and files) becomes accessible by users. After an unknown amount of time, subfolders revert back to inaccessible by user unless subfolder is kept "active" - like having it open in Dolphin. Permissions appear correct.

:~$ ll /shared
total 148
drwxrwsr-x 1 nobody shared 274 Jul 18 14:03 ./
drwxr-xr-x 1 root root 262 Jul 16 12:41 ../
drwxrwsr-x 1 nobody shared 120 Jul 6 11:49 Audio/
drwxrwsr-x 1 nobody shared 18 Jul 6 11:49 Backups/
-rw------- 1 nobody shared 35 Jul 7 13:42 .directory
drwxrwsr-x 1 nobody shared 612 Jul 8 09:12 Documents/

~$ ll /shared/Audio/
ls: cannot access '/shared/Audio/': Operation not permitted

~$ sudo ls /shared/Audio/
[sudo] password:
Audio Books Comedy Holiday Ringtones

:~$ ll /shared/Audio/
total 0
drwxrwsr-x 1 nobody shared 120 Jul 6 11:49 ./
drwxrwsr-x 1 nobody shared 274 Jul 18 14:03 ../
drwxrwsr-x 1 nobody shared 390 Jun 12 2011 Audio Books/
drwxrwsr-x 1 nobody shared 4882 May 22 14:49 Comedy/
drwxrwsr-x 1 nobody shared 166 Nov 22 2013 Holiday/
drwxrwsr-x 1 nobody shared 1290 Jul 7 2015 Ringtones/

fstab same for both client versions (15.04, 16.04):
server:/ /shared nfs4 auto,bg,soft,users,rsize=65536,wsize=65536,noatime,x-systemd.automount 0 0
server:/ /shared nfs4 auto,bg,soft,users,rsize=65536,wsize=65536,noatime,x-systemd.automount 0 0

export line from server:
/exports 192.168.1.0/24(rw,fsid=0,crossmnt,no_subtree_check,async,secure,nohide,all_squash,anonuid=65534,anongid=560)

client-side user groups: adm cdrom sudo dip backup plugdev users lpadmin sambashare wireshark shared

[Andreas Pinhammer (andreas-pinhammer)]

I've observed the same behaviour after upgrading my client from 14.04 to 16.04: root export of my nfs share is still accessible for user. But subfolder exports are not accessible anymore, although they are exported with crossmnt enabled. If I login as root user on client, all subfolders can be accessed without any problem.

On 14.04, everything worked just fine. Server configuration is unchanged.

fstab same for both client versions (14.04, 16.04):
nasnas:/ /media/nasnas nfs4 _netdev,auto,users 0 0

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[KeithP (keith-h5)]

We are also experiencing this issue -- any additional information on how to address this would be greatly appreciated.

[oshunluvr (stuartksmith)]

My workaround, an endless script using inotify running from rc.local:

--------
#!/bin.bash

while true #run indefinitely
do
inotifywait /shared/ >/dev/null 2>&1
ls /shared >nul
done
--------

This does a sudo listing of all the subdirectories of "/shared" anytime the root folder is accessed. Obviously, change /shared to match yours...

[oshunluvr (stuartksmith)]

I recently moved the KDEneon 5.7.4 from 16.04 (clean install) and this issue is not present there, so it's potentially possible this is already fixed upstream from 16.04.

I still have 16.04 and 15.04 available if any trouble shooting would be helpful...

[KeithP (keith-h5)]

Thank you for the feedback! I’m fairly new to Linux in general, however; I tried to implement the bash script by installing inotifywait and adding the script to the /etc/rc.local file. It doesn’t seem to do anything and when I do “ps – aux | grep inotifywait” the only thing which is returned is my grep statement. I’ve noticed that when I edit the rc.local file, it formats my share weirdly. I’m connecting to a DFS, so my share name is “/domain.com/h5”, however; when I edit the rc.local file in vi, it turns the “5” red, making me think it’s parsing “/h” as a switch. I’ve since put quotation marks around the share name, but that didn’t seem to make any difference. I was able to create an entry in the crontab which seems to accomplish the same thing:

*/5 * * * * /bin/ls /mnt/username >nul

Users used to be able to mount the drives themselves, as long as the drive mapping was listed in the fstab, but I’ve noticed that trying to mount requires sudo now, even if the share is listed in fstab:

//domain.com/h5 /mnt/username cifs user=WindowsUsersName,uid=username,gid=sudo,file_mode=0770,dir_mode=-0770 0 0

[oshunluvr (stuartksmith)]

Sorry for not being more complete. What I did was create the script (I
named it "keepalive" with the text I posted (all the stuff in-between the
dashed lines) and save it in the /root folder. It must be executable ( sudo
chmod +x /root/keepalive). Then call it from rc.local with /root/keepalive
.

Stuart Smith, from my Moto X

On Sep 9, 2016 5:11 PM, "KeithP" <email address hidden> wrote:

> Thank you for the feedback! I’m fairly new to Linux in general, however;
> I tried to implement the bash script by installing inotifywait and
> adding the script to the /etc/rc.local file. It doesn’t seem to do
> anything and when I do “ps – aux | grep inotifywait” the only thing
> which is returned is my grep statement. I’ve noticed that when I edit
> the rc.local file, it formats my share weirdly. I’m connecting to a DFS,
> so my share name is “/domain.com/h5”, however; when I edit the rc.local
> file in vi, it turns the “5” red, making me think it’s parsing “/h” as a
> switch. I’ve since put quotation marks around the share name, but that
> didn’t seem to make any difference. I was able to create an entry in the
> crontab which seems to accomplish the same thing:
>
> */5 * * * * /bin/ls /mnt/username >nul
>
> Users used to be able to mount the drives themselves, as long as the
> drive mapping was listed in the fstab, but I’ve noticed that trying to
> mount requires sudo now, even if the share is listed in fstab:
>
> //domain.com/h5 /mnt/username cifs
> user=WindowsUsersName,uid=username,gid=sudo,file_mode=0770,dir_mode=-0770
> 0 0
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1605230
>
> Title:
> sub-directories initially only accessible by root
>
> Status in nfs-utils package in Ubuntu:
> Confirmed
>
> Bug description:
> sub-directories initially only accessible by root
>
> Client: (K)Ubuntu 16.04 LTS - new install (not upgrade) fully up-to-date
> Server: Ubuntu 14.04 LTS - fully up-to-date
> Client Package: nfs-common 1:1.2.8-9ubuntu12
>
> No access issues using Kubuntu 15.04 client in the past or currently.
> Server configuration unchanged.
>
> Attempting to access all subfolders of NFS mount fails for user.
> Primary folder is listable, subfolders are not, files in first level
> folder are accessable. If a subfolder is accessed by root user, it
> (and all nested subfolders and files) becomes accessible by users.
> After an unknown amount of time, subfolders revert back to
> inaccessible by user unless subfolder is kept "active" - like having
> it open in Dolphin. Permissions appear correct.
>
> :~$ ll /shared
> total 148
> drwxrwsr-x 1 nobody shared 274 Jul 18 14:03 ./
> drwxr-xr-x 1 root root 262 Jul 16 12:41 ../
> drwxrwsr-x 1 nobody shared 120 Jul 6 11:49 Audio/
> drwxrwsr-x 1 nobody shared 18 Jul 6 11:49 Backups/
> -rw------- 1 nobody shared 35 Jul 7 13:42 .directory
> drwxrwsr-x 1 nobody shared 612 Jul 8 09:12 Documents/
>
> ~$ ll /shared/Audio/
> ls: cannot access '/shared/Audio/': Operation not permitted
>
> ~$ sudo ls /shared/Audio/
> [sudo] password:
> Audio Books Comedy ...

[KeithP (keith-h5)]

We tried to implement the fix as you described* and it doesn't seem to be working for us. We can confirm that the script is running, but we still get "Operation not permitted"...

*I had to change #!/bin.bash to #!/bin/bash to make it run

Any ideas?

Thanks.

[oshunluvr (stuartksmith)]

"*I had to change #!/bin.bash to #!/bin/bash to make it run" Silly typo, sorry.

Worked here. I ran it again and inotifywait shows up in processes. Try it from the command line like this:

while true; do inotifywait /shared/ >/dev/null 2>&1; ls /shared/* >/dev/null 2>&1; done

If this works, then it's your script. If not - I have no clue. My folder structure is simple,

/shared/
  /Documents
  /Music
  /Pictures

etc...